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:
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?
On 05.11.2013 12:16, Marek Goldmann wrote:
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
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
> upstream but also for some time now 4.X series has been available. In
> 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
> changes upstream that any maintainers of packages which depend on
> netty will
> need to be aware of. Those packages are:
> In addition, we currently have a compat netty31 package, which is used
> 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
> 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
> Any package currently using netty will *at least* require a search-and-
> replace for package/class name changes, and may require more indepth
> in order to work with the most recent upstream releases.
> The bulk of the changes came with the 4.0 release, and conveniently
> upstream made a single commit updating most of their example code at
> 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
> 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
> 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,
> for my email in a few weeks with .srpm to play with :)
> P.S. I *really* hope that at the end of all this we are not left with
> compat packages for netty, ie I hope that either eucalyptus is able to
> or that all of the others are able to port, or even better both of the
> java-devel mailing list
java-devel mailing list