java-devel October 2013

java-devel@lists.fedoraproject.org

19 participants
19 discussions

Missing org/apache/maven/archetype/catalog/ArchetypeCatalog
by John W. Himpel 27 Oct '13

27 Oct '13

Good evening, I hope this is the correct place to ask this type of question, if not, please provide a referral to the correct place. When creating a new maven project using eclipse in F19, I get: Problem Occurred 'Retrieving archetypes:' has encountered a problem. An internal error occurred during "Retrieving archetypes:" An internal error occurred during "Retrieving archetypes:". org/apache/maven/archetype/catalog/ArchetypeCatalog. I don't know if this is a packaging error or I haven't performed some necessary configuration work. Or perhaps my firewall isn't allowing communications with a central repository. To my knowledge, I haven't modified any configuration settings. Current packages that might be relevant: maven-eclipse-plugin-2.9-5 eclipse-m2e-core Suggestions appreciated. Thanks.

2 1

Upcoming jline change in rawhide.
by Severin Gehwolf 24 Oct '13

24 Oct '13

Hi, Currently jline2 (v 2.10) is the newest packaged version in Fedora. Note that there is another jline version packaged in Fedora, namely 1.x. However, jline2 is packaged as a compatibility package which is wrong. That's what's going to change. We are going to make jline what is jline2 now and move what is jline now to a new jline1 package. jline2 then gets retired with jline as its successor. For more information on compat packages please see Mikolaj's email this subject here: https://lists.fedoraproject.org/pipermail/java-devel/2013-October/005000.ht… I've filed bugs against all packages which have jline as a dependency (R/BR). Those packages might fail to build from source once jline is what jline2 currently is. All of those bugs are blocking the main tracker bug: https://bugzilla.redhat.com/show_bug.cgi?id=1022897 What do you have to do? Please make sure that your package builds using jline 2.x. If that's not the case we strongly advise to patch your package to work with newest jline. It would be best to propose such patches upstream for inclusion. If you really must, you may use the new jline1 compatibility package in rawhide. Please note that jline1 may get retired in a newer Fedora version however. That is why you should not change your BR/R to jline1 lightly. You have been warned :) Thanks for your help! Cheers, Severin

3 2

netty - request for comaintainer(s)
by Mikolaj Izdebski 24 Oct '13

24 Oct '13

I am the owner of package netty because it used to be required by Maven. Maven doesn't require it any longer, so I would prefer to give this package to someone else. Currently netty is required by a few other projects (including hadoop, resteasy, thermostat, wildfly), so I would expect maintainers of these packages to help with maintenance of netty by becoming comaintainers or taking ownership. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk

3 6

Headless JRE in Fedora
by Jiri Vanek 24 Oct '13

24 Oct '13

Hi all! With https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.60-2.4.3.0… beeing stable, would like to make this more visible: The jdk in Fedora, being inspired in Debian, now supports headless version. During the life of F20 (as in f21 all expected packages should be correctly headless)i would like to recommend all java packages maintainers, who do not need audio, or X or whatever (this is still "on QA" on our side) to swap theirs dependence to java-headless. Alos, maintainers, please do not forget, that when you update your package, also packages you are depending on must become "just hedless dependent". Anyway - all libraries should be jut java-headless :) I would like to suggest especially wildFly and tomcat to try to migrate asap, as this change was designed for them :) Btw - the update above is now somehow stuck - it not in testing, nor in updates. Maybe the relengs can help. Best regards J.

4 5

About compat packages
by Mikolaj Izdebski 24 Oct '13

24 Oct '13

Recently there were some discussions about compat packages on IRC. I wanted to present how I think compat packages should be used. I hope it will bring some sanity on this matter. Imagine the following situation. You are maintainer of a package. There is a new upstream version, but you know or suspect it may be incompatible with previous version and update could cause breakage for some dependants of your package. The first thing you should do is announce such update in advance. Try to be specific in terms of planned update schedule (what is going to happen at which point of time). Either send this announcement to some mailing list (devel or SIG) or to all maintainers of dependant packages. After discussing potential problems with interested parties you can proceed with updating your package. It's nice to have a consensus, but that's not always possible. After you prepared your update you can share it with other maintainers. You can use a repo on your fedorapeople.org account, a side tag in Koji or push it directly to rawhide. Then maintainers of dependant packages can test if their packages work with the updated version of your package and if not then take some action. Lets look at three different possibilities: Case 1. A dependant package works without change with the updated dependency version. That's great, it can immediately benefit from features and bugfixes of new version. Nothing more to do. Case 2. A dependant package needs a simple modification to work with updated version. Package maintainer prepares a patch, applies it in Fedora package and sent it upstream. Fedora package immediately starts to benefit from new version of dependency. Upstream can accept the patch and benefit too. Case 3. A dependant package does not work with new version of your package and needs some changes to port it. Package maintainer for some reason cannot prepare the patch (lack of time, skills etc.). Fedora package maintainer takes a copy of old version your library and turns it into a compatibility package. A comaintainer or other person reviews it and they add new package to Fedora. A RFE is sent to upstream asking to update to new dependency version. Hopefully in future upstream will implement the RFE and compatibility package will be removed from Fedora. To sum up, procedure of dang: 1. announce big updates in advance 2. push the update 3. fix dependant packages (if needed) 4. only if absolutely needed, package a compatibility version The above works in all cases. If you package newer version as compatibility package you are only preventing innovation and make dependant packages using old, obsolete software. Some (other) best practices: 0. Introduce compat packages only if absolutely needed. 1. All compat packages should have older version than default package. 2. Compat packages should have version suffixes, default package should not. 3. Compat packages should be retired as soon as they are no longer needed. 4. Prefer requires on default package, even if you need to patch your package -- Mikolaj Izdebski IRC: mizdebsk

1 0

Re: [fedora-java] [Fedora-packaging] Package Android Studio in Fedora 21/20
by Stanislav Ochotnicky 24 Oct '13

24 Oct '13

Quoting Petr Hracek (2013-10-23 12:25:58) > Hello folks, > > I would like to package Android Studio in Fedora 20/21. > The URL for Android Studio is > (http://developer.android.com/sdk/installing/studio.html) > > What do you think about it? > Is it possible to package the IDE? Possible? Sure, anything is... Feasible? Unlikely > What about the license? I couldn't even bother going through the steps to get to the source code...It's just too damn hard[1]. So...no idea about license but there would likely be a few glitches > > If it is not possible to package them into Fedora, > can we use rpmfusion non-free as a plugin? As Dridi mentioned, this is based on IntelliJ IDEA (or however it's capitalized). It uses some custom build scripts to build, internally uses gradle to actually build those android projects...It's a mess on top of mess. Yes, people could package it. But it would take some serious effort and is definitely not a one-man-job. Not to mention maintaining it afterwards. We have enough packaged and unmaintained software in Java world as it is... As for rpmfusion: rpmfusion has *identical* guidelines to Fedora. Only difference is that they let in patented stuff (more or less). You can't package something with unclear licensing or redistribution problems in rpmfusion either. > Thank you very much. Yeah, I don't think you like my answer but... [1] http://source.android.com/source/downloading.html -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- packaging mailing list packaging(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging

1 0

spring-* vs springframework-*
by Orion Poplawski 21 Oct '13

21 Oct '13

I'd like to get some kind of consensus on naming of the spring/springframework packages. We have some of both: spring-ldap-javadoc.noarch spring-ldap.noarch spring-maps-default.noarch spring-retry-javadoc.noarch spring-retry.noarch springframework-aop.noarch springframework-beans.noarch springframework-context-support.noarch springframework-context.noarch springframework-expression.noarch springframework-instrument.noarch springframework-javadoc.noarch springframework-jdbc.noarch springframework-jms.noarch springframework-orm.noarch springframework-oxm.noarch springframework-security-javadoc.noarch springframework-security.noarch springframework-struts.noarch springframework-tx.noarch springframework-web.noarch springframework-webmvc-portlet.noarch springframework-webmvc.noarch springframework.noarch The core/parent package is currently "springframework", but one could argue it should be called "spring-framework". I think the spring-* names more closely match current upstream. However, "spring" itself is: Name : spring Arch : x86_64 Version : 94.1 Release : 3.fc19 Size : 16 M Repo : updates/19/x86_64 Summary : Multiplayer, 3D realtime strategy combat game URL : http://springrts.com License : GPLv2+ and GPLv3+ and LGPLv2 and GFDL and (GFDL or CC-BY) Description : Spring is a project aiming to create a new, versatile, full 3D Real Time : Strategy Engine. : Spring is designed to be played as online multiplayer matches, but some AI are : also available to play against the computer. : Please read the README.Fedora file to get started. The Spring wiki is also a : great resource, read it here: http://spring.clan-sy.com/wiki/Main_Page and spring-installer is a helper program for spring. springframework-* seems to have been what is most commonly used and probably what we should standardize on? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

4 3

XMvn 1.2.0 release notes
by Mikolaj Izdebski 18 Oct '13

18 Oct '13

What's new in XMvn 1.2.0 * Minor features * Artifact information in manifests Since version 1.2.0 XMvn injects artifact coordinates to manifests of artifact files it installs. XMvn Subst can read this information and use it to locate artifacts in the system. This way artifacts that do not contain pom.properties can still be correctly replaced with symbolic links by XMvn Subst. * Artifacts using native code Previous versions only tried to detect artifacts containing native code. In addition to that XMvn version 1.2.0 also attempts to detect JAR files using native code. This means that such JARs can be installed to a different location than JARs not containing and not using native code. * Major bugfixes * Stereotype support in auto-requires XMvn Installer did not take into account artifact stereotypes. This caused generated auto-requires to be incorrect in some cases. This bug was partially fixed by embedding default Maven artifact type mappings. This means that any non-standard stereotypes may still be handled incorrectly and produce unsatisfiable dependencies. * Generated self-requires Auto-requires generator was corrected to generate correct auto-requires in complex cases involving compatibility versions, namespaces and dependencies on artifacts provided by the same package.

1 0

Java Packages Tools 3.4.0 release notes
by Mikolaj Izdebski 14 Oct '13

14 Oct '13

Java Packages Tools 3.4.0 was released and pushed to rawhide. Changes in this version are described below. Some error messages that cause build failure were improved to make it more clear what they mean. A lot of test cases were added. Existing test cases were extended and improved. Some legacy manual pages were rewritten from scratch. Some others were fixed or updated. Now injected pom.properties contain classifiers and extensions which means that XMvn Subst will be able to locate JAR files with classifiers or nonstandard extensions. Several bugs related to namespaces (related to software collections) were fixed. Two bugs related to handling whitespace in XML were fixed. Python implementation was fully migrated from "xml.dom" to "lxml" DOM. Compatibility with Python 2.6 was improved. Java packaging HOWTO was extended and improved.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel October 2013