mvn virtual packages (auto-provides/requires)
by Mikolaj Izdebski
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
10 years, 6 months
javapackages-tools 3.0.x release notes
by Stanislav Ochotnicky
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
10 years, 6 months
Fwd: [jboss-rpm] WildFly available in Fedora!
by Marek Goldmann
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
10 years, 6 months
XMvn 1.0.0 release notes
by Mikolaj Izdebski
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.
10 years, 6 months
JAVA Native Splash Screen Guidance
by mray271
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
10 years, 6 months