Heads-up: netty update to 4.0.28 coming in rawhide.
by Severin Gehwolf
Hi,
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:
hornetq-0:2.4.1-5.fc23.x86_64
jython-0:2.7-1.fc23.noarch
netty-xnio-transport-0:0.1.1-0.4.CR2.fc21.noarch
spark-0:0.9.1-0.3.rc3.fc21.x86_64
wildfly-0:8.1.0-3.fc22.noarch
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
later tomorrow.
Cheers,
Severin
8 years
Proposal to deprecate _prefer_jre
by Mikolaj Izdebski
_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?
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
8 years
Gradle Fedora integration
by Mikolaj Izdebski
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?
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
8 years
Eclipse Docker Tooling and Jersey 2.x
by Roland Grunberg
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 [1]. One of the project's dependencies is on a Java
implementation of the Docker Remote API [2], 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
version ?
This may affect other packages so I thought I'd at least post to make
others aware.
Cheers,
--
Roland Grunberg
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1218315
[2] https://github.com/spotify/docker-client
8 years, 1 month
XMvn 2.4.0 release notes
by Mikolaj Izdebski
What's new in XMvn 2.4.0
XMvn 2.4.0 was released on 2015-05-06. Most important changes
include:
* 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
XMvn release.
* 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
cache directory.
8 years, 1 month