[fedora-java] Heads-up: Upcoming netty major version update in Rawhide (Will Break Stuff)

[Marek Goldmann]

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 at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/java-devel
>>
> --
> java-devel mailing list
> java-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel