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/8237afff64509520865c08bf4f5fd130e06aed...
On Thu, Oct 24, 2013 at 11:11 AM, Jon VanAlten jvanalte@redhat.com 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.
I'm currently working on making Eucalyptus 3.3.2 available in Fedora 18/19, and this version still requires the netty31 compat package. Version 3.4.0 of Eucalyptus, which was just released, had its dependency on netty updated to 3.6.6. It required a fair amount of internal changes to make that update possible, so updating yet again to netty 4.0 may be difficult. I'll be starting work on Eucalyptus 3.4.0 in rawhide soon and can try using your srpm when available. So, netty 4.0 is a maybe and netty31 won't be needed for Eucalyptus in rawhide.
[1] https://github.com/netty/netty/commit/8237afff64509520865c08bf4f5fd130e06aed... -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
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.
I'm currently working on making Eucalyptus 3.3.2 available in Fedora 18/19, and this version still requires the netty31 compat package. Version 3.4.0 of Eucalyptus, which was just released, had its dependency on netty updated to 3.6.6. It required a fair amount of internal changes to make that update possible, so updating yet again to netty 4.0 may be difficult. I'll be starting work on Eucalyptus 3.4.0 in rawhide soon and can try using your srpm when available. So, netty 4.0 is a maybe and netty31 won't be needed for Eucalyptus in rawhide.
Ah, very good thanks for the update. Glad to hear we'll be able to drop netty31 from rawhide. Just to be clear, I don't plan to maintain any compat package for netty; if (and I agree this is likely to be difficult) 4.0 is not a reasonable option then it'll be up to someone else (maybe you?) to create compat package for 3.6.6 once the update is pushed. I'll communicate loudly as this time approaches, so that nobody is caught off guard.
cheers, jon
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/8237afff64509520865c08bf4f5fd130e06aed...
java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
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/8237afff64509520865c08bf4f5fd130e06aed...
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On 11/05/2013 12:36 PM, Marek Goldmann wrote:
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?
That will be difficult.
Wildfly is not the only user of Netty. In fact several other applications are using it too. But if you get maintainers of all applications using Netty to agree and if Netty was first tested in rawhide for long enough then I can update it in Fedora 20 too.
Quoting Marek Goldmann (2013-11-05 12:36:33)
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?
There's an idea (even if an ugly one) to package netty4 in F20 only (keeing netty package there on 3.x). In F21+ we'd migrate all other packages to netty 4.x, update netty package to 4.x and make it obsolete netty4 from F20.
With XMvn there would be no (or minor) changes needed to packages that would like to build against 4.x (and those changes would likely work in rawhide as well). Most like all you'd have to do is ifdef for (build)requires.
Stano,
I think this is the route I would like to go. I'm happy to create a netty4 compat package based on what Jon creates for netty package in Rawhide.
--Marek
On 05.11.2013 15:49, Stanislav Ochotnicky wrote:
Quoting Marek Goldmann (2013-11-05 12:36:33)
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?
There's an idea (even if an ugly one) to package netty4 in F20 only (keeing netty package there on 3.x). In F21+ we'd migrate all other packages to netty 4.x, update netty package to 4.x and make it obsolete netty4 from F20.
With XMvn there would be no (or minor) changes needed to packages that would like to build against 4.x (and those changes would likely work in rawhide as well). Most like all you'd have to do is ifdef for (build)requires.
Jon,
Any progress on this?
It seems that I'll need the netty 4 package very soon for hornetq and wildfly updates.
--Marek
On 06.11.2013 10:38, Marek Goldmann wrote:
Stano,
I think this is the route I would like to go. I'm happy to create a netty4 compat package based on what Jon creates for netty package in Rawhide.
--Marek
On 05.11.2013 15:49, Stanislav Ochotnicky wrote:
Quoting Marek Goldmann (2013-11-05 12:36:33)
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?
There's an idea (even if an ugly one) to package netty4 in F20 only (keeing netty package there on 3.x). In F21+ we'd migrate all other packages to netty 4.x, update netty package to 4.x and make it obsolete netty4 from F20.
With XMvn there would be no (or minor) changes needed to packages that would like to build against 4.x (and those changes would likely work in rawhide as well). Most like all you'd have to do is ifdef for (build)requires.
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
OK, a few news from me on this topic. I made following:
1. Prepared a netty4 compat package for F20 *only*, 2. Prepared a netty package upgrade from version 3 to 4 for Rawhide, 3. Prepared a netty3 compat package for Rawhide.
These packages are available here:
http://goldmann.fedorapeople.org/netty/
It would be great to not introduce netty3 package into Rawhide. We should do everything to not require it :)
I would need a bit of help from you:
1. Please make sure these packages are OK (I still need to to add the Obsoletes and so on) The .src.rpm files are there too. 2. Please test your packages against these (new netty from Rawhide) packages.
I would like to proceed with the upgrade ASAP, since wildfly 8.0.0.CR1 was already released and its dependencies require upgrade to netty 4.
Thanks!
--Marek
On 16.12.2013 14:53, Marek Goldmann wrote:
Jon,
Any progress on this?
It seems that I'll need the netty 4 package very soon for hornetq and wildfly updates.
--Marek
On 06.11.2013 10:38, Marek Goldmann wrote:
Stano,
I think this is the route I would like to go. I'm happy to create a netty4 compat package based on what Jon creates for netty package in Rawhide.
--Marek
On 05.11.2013 15:49, Stanislav Ochotnicky wrote:
Quoting Marek Goldmann (2013-11-05 12:36:33)
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?
There's an idea (even if an ugly one) to package netty4 in F20 only (keeing netty package there on 3.x). In F21+ we'd migrate all other packages to netty 4.x, update netty package to 4.x and make it obsolete netty4 from F20.
With XMvn there would be no (or minor) changes needed to packages that would like to build against 4.x (and those changes would likely work in rawhide as well). Most like all you'd have to do is ifdef for (build)requires.
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
OK, I've created a review request for netty4:
https://bugzilla.redhat.com/show_bug.cgi?id=1047851
--Marek
On 30.12.2013 16:17, Marek Goldmann wrote:
OK, a few news from me on this topic. I made following:
- Prepared a netty4 compat package for F20 *only*,
- Prepared a netty package upgrade from version 3 to 4 for Rawhide,
- Prepared a netty3 compat package for Rawhide.
These packages are available here:
http://goldmann.fedorapeople.org/netty/
It would be great to not introduce netty3 package into Rawhide. We should do everything to not require it :)
I would need a bit of help from you:
- Please make sure these packages are OK (I still need to to add the
Obsoletes and so on) The .src.rpm files are there too. 2. Please test your packages against these (new netty from Rawhide) packages.
I would like to proceed with the upgrade ASAP, since wildfly 8.0.0.CR1 was already released and its dependencies require upgrade to netty 4.
Thanks!
--Marek
On 16.12.2013 14:53, Marek Goldmann wrote:
Jon,
Any progress on this?
It seems that I'll need the netty 4 package very soon for hornetq and wildfly updates.
--Marek
On 06.11.2013 10:38, Marek Goldmann wrote:
Stano,
I think this is the route I would like to go. I'm happy to create a netty4 compat package based on what Jon creates for netty package in Rawhide.
--Marek
On 05.11.2013 15:49, Stanislav Ochotnicky wrote:
Quoting Marek Goldmann (2013-11-05 12:36:33)
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?
There's an idea (even if an ugly one) to package netty4 in F20 only (keeing netty package there on 3.x). In F21+ we'd migrate all other packages to netty 4.x, update netty package to 4.x and make it obsolete netty4 from F20.
With XMvn there would be no (or minor) changes needed to packages that would like to build against 4.x (and those changes would likely work in rawhide as well). Most like all you'd have to do is ifdef for (build)requires.
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
java-devel@lists.fedoraproject.org