OK, I have new info on this.
Netty is actually pulled by HornetQ, WildFly JMS implementation. There
is an open bug upstream to upgrade to Netty 4:
https://issues.jboss.org/browse/HORNETQ-1215
The fix version is the next release (2.4.0.CR1) and this version will be
used by next pre-release (and later Final of course) of WildFly. As you
can imagine I want to package it for Fedora 20 and Rawhide. I don't want
to leave Beta1 in Fedora 20.
So, here is the thing:
This would require upgrading netty in Fedora 20 too, because if we don't
do it - WildFly will not be able to get any new updates to Fedora 20
which is a tragedy for me :)
Is it doable, any ideas?
--Marek
On 05.11.2013 12:16, Marek Goldmann wrote:
Hi Jon,
Thanks for the info!
There is another big player in the game: WildFly. It requires currently
3.6.6.Final. I'm not sure how well it'll play with Netty 4 and I don't
think that for Final they'll switch to version 4.
P.S. It's an actual bug that it does not have netty listed in Requires.
Without this the standalone-full.xml configuration won't work. I created
a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1026752
--Marek
On 24.10.2013 20:11, Jon VanAlten wrote:
Hi Java folks,
The current netty in Fedora is 3.6.3. There are newer updates to 3.X
series
upstream but also for some time now 4.X series has been available. In
the
spirit of keeping the most up to date version in our distro, I
aim/plan to
update this in rawhide in the coming weeks. However, there have been
some
changes upstream that any maintainers of packages which depend on
netty will
need to be aware of. Those packages are:
async-http-client
bookkeeper
eclipse-m2e-core
hadoop
hornetq
littleproxy
resteasy
thermostat
zookeeper
In addition, we currently have a compat netty31 package, which is used
only
by the eucalyptus package. I'd also like to encourage the maintainer of
eucalyptus to look into porting to the newer netty, so this longstanding
compat package can be retired. (Well, there are other packages that
"repoquery --whatrequires netty31" returns, but inspection of .spec shows
that they only Require: netty without a version; only eucalyptus has an
explicit requirement for netty31.)
So, what are the implications of this update? Well, upstream netty has
moved from being a jboss project to being independent at netty.io, and
has
changed their package namespace accordingly. In addition, some key API
classes have slightly changed names. Finally, and I haven't looked
deep at
this part yet, but it seems there are some other incompatible API
changes.
Any package currently using netty will *at least* require a search-and-
replace for package/class name changes, and may require more indepth
fixes
in order to work with the most recent upstream releases.
The bulk of the changes came with the 4.0 release, and conveniently
enough
upstream made a single commit updating most of their example code at
once[1]
which is likely to be a good reference for anyone porting an application.
I'll be starting on this work around mid-November. My plan is to first
create package of the newest netty release at the time but not push to
rawhide just yet, rather make srpm available to interested maintainers
via
other means. Then, as co-maintainer of thermostat, I will help to
port that
package to the new netty API. I hope around this same time
maintainers of
other packages will do same. To me, this will act as "sanity check"
for the
updated netty package, and if this check is successful, I'll then push
the
netty changes to rawhide. If all goes well, this should be done by
the end
of November (modulo a week or so).
Please, if you have any concerns with this plan, speak up! Otherwise,
wait
for my email in a few weeks with .srpm to play with :)
cheers,
jon
P.S. I *really* hope that at the end of all this we are not left with
*two*
compat packages for netty, ie I hope that either eucalyptus is able to
port
or that all of the others are able to port, or even better both of the
above.
[1]
https://github.com/netty/netty/commit/8237afff64509520865c08bf4f5fd130e06aed92
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
