java-devel September 2013

java-devel@lists.fedoraproject.org

11 participants
15 discussions

mvn virtual packages (auto-provides/requires)
by Mikolaj Izdebski 11 Sep '13

11 Sep '13

Java Packages Tools version 3.0.0 has recently been pushed to rawhide. Since this version virtual packages generated automatically for Maven artifacts (aka auto-provides) were extended slightly. In this email I will describe briefly the new format of virtual package names. All Maven virtual package names used to be in format: mvn(groupId:artifactId) = version This has recently been extended to four different forms: mvn(groupId:artifactId) = version mvn(groupId:artifactId:compatVersion) = version mvn(groupId:artifactId:extension:compatVersion) = version mvn(groupId:artifactId:extension:classifier:compatVersion) = version * groupId and artifactId are upstream identifiers of the artifact. Version is artifact version, as set by upstream. * compatVersion is the compatibility version assigned by package maintainer. This is Fedora-specific. compatVersion can differ from version. * extension is extension of artifact file, for example jar, war, pom, tar.gz and so on. If extension is omitted then it defaults to jar. * classifier is artifact classifier. This email describes only one feature of javapackages-tools-3.0.0. Full release notes will be provided by Stanislav Ochotnicky in a separate email. -- Mikolaj Izdebski IRC: mizdebsk

3 3

javapackages-tools 3.0.x release notes
by Stanislav Ochotnicky 11 Sep '13

11 Sep '13

As Mikolaj already pointed out most important part of new javapackages-tools visible from packager's POV (classifiers/extensions in provides/requires), I'll summarize the rest. * Features ** Add %mvn_compat_version macro This provides integration with XMvn to support compatibility packages. Simple macro invocation %mvn_compat_version : %{version} will result in package only providing versioned provides. This is now enough to create compat package from non-compat package with XMvn ** python library for handling pom.xml files, fragment files This was split off from maven.req/maven.prov to deduplicate code and enable better testing. Contained in python-javapackages RPM, the library is usable from python prompt. Just do: >>> import javapackages >>> help(javapackages) ** Support for extended Maven artifact specification In each place that previously accepted groupId:artifactId pair, it is currently possible to use full specification: groupId:artifactId[:extension[:classifier]][:version] if extension or classifier are included but version is not, the specification must end with colon (":") to ensure we can distinguish between variations. ** add_maven_depmap macro support for artifacts without pom.xml First argument of add_maven_depmap macro can now be a Maven artifact specification instead of pom.xml file. This specification has to include version. ** Improved mvn_alias macro It's currently possible to omit parts of alias definitions and they will be filled from main artifact. Example: %mvn_alias gId:aId :alternative Would create alias for gId:alternative * Bugfixes ** (#977975) Improve adding POM dependencies and plugins ** (#977977) Improve pom_ macros to preserve whitespace and indentation ** (#998322) add_pom_dep_mgmt injects incorrect xml ** (#998463) whitespace breaks XML node matching for pom macros * Improvements ** Set of unit tests for mvn_ macros and RPM provides/requires generation library (maven.prov and maven.req TBD) ** Documentation added for library part of javapackages -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

1 0

Fwd: [jboss-rpm] WildFly available in Fedora!
by Marek Goldmann 10 Sep '13

10 Sep '13

WildFly in Fedora - things looking good, read below :) -------- Original Message -------- Subject: [jboss-rpm] WildFly available in Fedora! Date: Tue, 10 Sep 2013 10:40:58 +0200 From: Marek Goldmann <mgoldman(a)redhat.com> To: jboss-rpm(a)lists.jboss.org <jboss-rpm(a)lists.jboss.org> Hi All, Great news - WildFly Application Server is now available in Fedora Rawhide (and soon in Fedora 20 too!). Thanks to Mikołaj - I finished the review process for the wildfly package yesterday: https://bugzilla.redhat.com/show_bug.cgi?id=995045 Please join me in helping all the people involved in this process, especially Gil Cattaneo and Mikołaj Izdebski. Those guys really helped me! The jboss-as package is now retired in Fedora 20+. If you try to install jboss-as, wildfly will be picked up automatically. After you test wildfly in Fedora 20, please bump the karma for the package: https://admin.fedoraproject.org/updates/wildfly-8.0.0-0.6.Alpha3.fc20 If you're interested in receiving mails about issues assigned to wildfly and/or want to be up to date with the updates - please add yourself to the wildfly package: https://admin.fedoraproject.org/pkgdb/acls/name/wildfly What's next? Glad you ask :) The next step is to upgrade to 8.0.0.Alpha4 of course. This will simplify the package. Over the next weeks I'll test the package and fix all issues. If you find some on your own - please report them in Bugzilla for the wildfly component: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=wildfly I've created a Change proposal for the upcoming Fedora 20 where I would like to see WildFly being highlighted as a Feature: https://fedoraproject.org/wiki/Changes/WildFly8 Unfortunately the time for submitting Features is now over, but I'm working for an exception. Wish me luck :) Thanks! --Marek _______________________________________________ jboss-rpm mailing list jboss-rpm(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-rpm

2 3

XMvn 1.0.0 release notes
by Mikolaj Izdebski 09 Sep '13

09 Sep '13

What's new in XMvn 1.0.0 * Major features * Flexible repositories Since version 1.0.0 XMvn has a new way of configuring repositories from which artifacts are resolved and to which they are installed. Several aspects of artifact resolution which were hardcoded in previous versions of XMvn are configurable since version 1.0.0. * Classifiers and extensions Previous versions of XMvn lacked support for artifact classifiers and for artifact extensions other than <<<jar>>> and <<<pom>>>. Since version 1.0.0 XMvn supports resolution and installation of artifacts with any classifier and extension. * Compatibility versions Although previous versions were able to resolve versioned artifacts (also knows as compatibility versions), there was no support for installing versioned artifacts. Since version 1.0.0 XMvn fully supports compatibility versions -- it is able to both resolve and install versioned artifacts. * Installing artifacts not produced in reactor Sometimes there is a need to install artifacts not produced in Maven reactor, but generated by other means, like custom script or other build system. Since version 1.0.0 XMvn allows installation of such artifacts along with artifacts produced by Maven build. * Artifact namespaces XMvn 1.0.0 allows artifacts to have namespaces, which limits possible name clashes and allows several versions of the same artifact to be installed more easily without the need to use compatibility versions. This feature can be used to implement support for software collections. * Minor features * Improved performance of resolver Reading depmap fragments is the dominant operation when running short-living tools like XMvn Resolve or XMvn Subst. Since version 1.0.0 depmaps are being read in parallel, which improves performance on multi-processor systems. * Improved build-requires generator Dependency did not include all possible cases when generating build-requires. This has been improved in XMvn 1.0.0. * Improved support for compatibility versions Versioned artifacts are now resolved in simpler and more obvious way. * Improved handling of Java versions Besides standard versions like 1.4 or 1.7 XMvn now recognizes other visioning schemes like 7.0 or 7, as well as <<<jsr14>>> and <<<cldc1.1>>>. * Improved error handling in command-line tools Command like tools now print better error messages and are less likely to print stack traces for user errors. * Minor bugfixes * Possible concurrency bug when creating symbolic links Possible concurrency bug when creating symbolic links was avoided by using file system atomic operations, if supported by file system.

1 0

JAVA Native Splash Screen Guidance
by mray271 06 Sep '13

06 Sep '13

There doesn't seem to be any official guidance on how to show splash images for Java applications packaged for Fedora in <http://fedoraproject.org/wiki/Packaging:Java> . I am hoping the following with lead to discussion and ultimately to a standard approach. In short, I believe the issue can be addressed through Fedora packaging guidelines without violating canonical JPackage guidelines. Indeed, the JPackage guidelines http://www.jpackage.org don't seem to address splash images at all. BACKGROUND: According to http://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html "...the main purpose of a splash screen is to provide the user with feedback about the application's startup, the delay between the application's startup and the moment when the splash screen pops up should be minimal" [1] Currently, JAVA supports only the 2 following mechanisms to display such a splash screen: 1) Command-line argument 2) Java™ Archive (JAR) file with the specified manifest option For JAVA applications packaged in Fedora, 2) is not possible since executable .jar files are not allowed according to guidelines http://fedoraproject.org/wiki/Packaging:Java. In Fedora, the /usr/share/java-utils/java-functions are used. In contrast, for 1) to work, a path to an image file residing on the file system must be given. This differs sharply from 2) where the splash image must be a resource packaged in the application jar file and indicated as the SplashScreen-Image in the jar's manifest. PROPOSAL: The following work-around convention is suggested and is open for discussion: Fedora Java packages that wish to show a splash screen prior to their package's main class running, should place an image in the directory /usr/share/splash following the convention <fedora-package-name>.<ext> where ext is one of the standard splash image file types (e.g. .png, .gif, .jpg). For applications wishing to show a splash screen, package maintainers should then put a line in the package's JPackage launch script similar to: BASE_FLAGS="-splash:/usr/share/splash/<fedora-package-name>.<ext>" RPM/SPEC CONSIDERATIONS: A reasonably common situation will be that a jar resource spash image will already exist within the sources of JAVA applications wanting to show a splash image. Fedora package maintainers can easily use maven or ant build tactics to 1) copy the image from RPM sources or 2) extract image resource from the packaged jar file and rename to /usr/share/splash/<fedora-package-name>.<ext> during Fedora package %build and/or %install etc. [1] Some applications currently packaged in Fedora (e.g. Jabref) go to some lengths to circumvent the issue altogether and use custom undecorated JFrame or Window class instances to programmatically show a "splash screen" followed by a timed delay prior to making their main application window visible to the user. However such forced "splash screens" are only shown after the JVM has already fully started and must then impose a further delay by showing the splash for some predetermined time (e.g. 2 seconds). This circumvents the "main purpose of a splash screen" mentioned in http://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html -- Dan Dougherty

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel September 2013