I'm about to update netty to upstream release 4.0.28 in rawhide in order
to fix a CVE bug. Packages which might be affected are:
Please let me know if this is going to break your package and we can
sort out how we are going to fix it. I'll be pushing the build to koji
_prefer_jre is environmental variable, which once set to true causes
javapackages-tools to prefer JRE over JDK when choosing JVM to use.
_prefer_jre was most useful in multi-JVM scenario. For example when
there was JDK 1.5 and JRE 1.7 installed, javapackages-tools would choose
JDK 1.5 by default. Setting _prefer_jre=true would allow more recent JRE
1.7 to be used instead.
Currently in Fedora there is only one Java implementation. Moreover,
with Java 9 distinction between JDK and JRE becomes less clear.
Therefore I propose to deprecate _prefer_jre environmental variable and
remove it in a future release of javapackages-tools, in a year or so.
Any objections or comments?
Software Engineer, Red Hat
I had some Gradle-related TODO items waiting for a couple of months, but
I didn't have time to implement them yet.
1) /usr/bin/gradle-local script
This script would run Gradle in "local mode" - all dependencies are
first resolved from Fedora packages, but in case some artifact is not
available, the original repositories used in build script are uesd.
2) %gradle_build macro
This macro would build the project in local, offline mode and mark all
artifacts as installable with %mvn_install.
3) Gradle in "Java packaging HOWTO"
There should be an entry in HOWTO describing how to package Gradle projects.
What do you think about them? Would you like to see some of them
implemented? If yes, which ones?
Software Engineer, Red Hat
For the past little while I've spent time working on providing Docker
Image/Container management capabilities for the Eclipse IDE. This
work has been done upstream and for the time being, will be offered under
the Linux Tools Project. You can take a look at what's currently available
at http://tools.jboss.org/blog/2015-03-30-Eclipse_Docker_Tooling.html .
In preparation for getting this plugin into Fedora, I've looked over its
dependencies and it seems that nearly all are present in Fedora at an
acceptable version. The only dependencies that will require a bit of work
are for Jersey . One of the project's dependencies is on a Java
implementation of the Docker Remote API , which requires Jersey 2.x and
it seems that the latest in Fedora is 1.18.3. There seem to be a few
packages that currently depend on Jersey 1.x (ambari, hadoop, hbase, oat).
Does it make sense to update to Jersey 2.x while maintaining a
compatibility version (jersey1) for packages that can't use the newer
This may affect other packages so I thought I'd at least post to make
What's new in XMvn 2.4.0
XMvn 2.4.0 was released on 2015-05-06. Most important changes
* Major features
* Support for Mock pm_request plugin
XMvn 2.4.0 supports on-demand artifact installation via Mock
pm_request plugin. When this plugin is enabled then XMvn will
try to install any missing artifacts instead of failing.
* Major bugfixes
* Java requires
Generation of Java requires (rhbz#1086335) was fixed in this
* Minor features
* Effective POM caching
XMvn 2.4.0 fixes tries to avoid creating polluting system with
temporary files. In particular effective POMs are cached in XDG