4:20 p.m.
Hi guys,
This is of interest for infinispan, web & messaging subsystem and the test suite.
As a part of upgrading HornetQ to 2.3.O.BETA1 in AS7[1], we also need to upgrade its
dependency to Netty 3.4.5.Final[2].
Inside AS7, the Web subsystem also depends on Netty. Guys, is it ok for you to upgrade to
3.4.5?
Unfortunately, to move from Netty 3.2.x to Netty 3.4.x, we must also change its groupId
from org.jboss.netty to io.netty.
If I do that, I can no longer build AS7 test suite because of bad dependencies which
requires Netty 3.2.x:
+-org.jboss.as:jboss-as-testsuite:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-build:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-core-model-test:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-model-test:7.2.0.Alpha1-SNAPSHOT
+-org.sonatype.aether:aether-connector-asynchttpclient:1.13.1
+-com.ning:async-http-client:1.6.5
+-org.jboss.netty:netty:3.2.5.Final
and
+-org.jboss.as:jboss-as-testsuite:7.2.0.Alpha1-SNAPSHOT
+-org.projectodd.stilts:stilts-stomp-client:0.1.26
+-org.projectodd.stilts:stilts-stomp-api:0.1.26
+-org.jboss.netty:netty:3.2.1.Final
Since only the test suite depends on Netty 3.2.x, in my PR, I have 2 versions of Netty:
* io.netty Netty 3.4.5.Final => used by AS7 codebase
* org.jboss.netty Netty 3.2.x => used by AS7 test suite
This is ugly but this works...
However, I'd like to reconcile these 2 versions and upgrade everything to 3.4.5.Final
I have submitted patches for Stilts[3] and Aether connector[4] to upgrade their
dependencies to Netty 3.4.x (groupId=io.netty).
Until they release new versions of their components, we are stuck with Netty 3.2.x.
Another question is about the recent upgrade to Infinispan 5.2.0.BETA1[5]. When I look at
this version's POM[6], it depends on
Netty 3.4.6.Final. Shouldn't have Netty been updated at the same time than
Infinispan?
If that's not required to upgrade a component dependencies when the component is
upgraded, I could postpone Netty 3.4.x upgrade.
However some HornetQ bugs requires this version (e.g. for WebSockets support[7]). I really
want to keep the AS7 dependencies in
sync with the deps of HornetQ that is integrated.
wdyt?
jeff
[1] https://issues.jboss.org/browse/AS7-5683
[2] https://issues.jboss.org/browse/AS7-5402
[3] https://github.com/projectodd/stilts/pull/8
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=391233
[5]
https://github.com/jbossas/jboss-as/commit/7107c3abcd6220f71380b3602398ed...
[6] https://github.com/infinispan/infinispan/blob/5.2.0.Beta1/parent/pom.xml#...
[7] https://issues.jboss.org/browse/HORNETQ-819
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
4:33 p.m.
This is not the first time a group ID has changed. What you have to do is:
1. Examine dependency:tree and add exclusions to every project pulling
in Netty in the main POM (this should already have been done, since
*every* artifact should have all its transitives excluded, but people
are getting lazy about this). You may have to run dependency:tree
several times to find them all.
2. Add an enforcer rule to ban the old coordinates.
3. Replace the old dependency with the new one in all modules that
require Netty directly or transitively.
4. Test!
On 10/05/2012 09:20 AM, Jeff Mesnil wrote:
Hi guys,
This is of interest for infinispan, web & messaging subsystem and the test suite.
As a part of upgrading HornetQ to 2.3.O.BETA1 in AS7[1], we also need to upgrade its
dependency to Netty 3.4.5.Final[2].
Inside AS7, the Web subsystem also depends on Netty. Guys, is it ok for you to upgrade to
3.4.5?
Unfortunately, to move from Netty 3.2.x to Netty 3.4.x, we must also change its groupId
from org.jboss.netty to io.netty.
If I do that, I can no longer build AS7 test suite because of bad dependencies which
requires Netty 3.2.x:
+-org.jboss.as:jboss-as-testsuite:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-build:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-core-model-test:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-model-test:7.2.0.Alpha1-SNAPSHOT
+-org.sonatype.aether:aether-connector-asynchttpclient:1.13.1
+-com.ning:async-http-client:1.6.5
+-org.jboss.netty:netty:3.2.5.Final
and
+-org.jboss.as:jboss-as-testsuite:7.2.0.Alpha1-SNAPSHOT
+-org.projectodd.stilts:stilts-stomp-client:0.1.26
+-org.projectodd.stilts:stilts-stomp-api:0.1.26
+-org.jboss.netty:netty:3.2.1.Final
Since only the test suite depends on Netty 3.2.x, in my PR, I have 2 versions of Netty:
* io.netty Netty 3.4.5.Final => used by AS7 codebase
* org.jboss.netty Netty 3.2.x => used by AS7 test suite
This is ugly but this works...
However, I'd like to reconcile these 2 versions and upgrade everything to
3.4.5.Final
I have submitted patches for Stilts[3] and Aether connector[4] to upgrade their
dependencies to Netty 3.4.x (groupId=io.netty).
Until they release new versions of their components, we are stuck with Netty 3.2.x.
Another question is about the recent upgrade to Infinispan 5.2.0.BETA1[5]. When I look at
this version's POM[6], it depends on
Netty 3.4.6.Final. Shouldn't have Netty been updated at the same time than
Infinispan?
If that's not required to upgrade a component dependencies when the component is
upgraded, I could postpone Netty 3.4.x upgrade.
However some HornetQ bugs requires this version (e.g. for WebSockets support[7]). I
really want to keep the AS7 dependencies in
sync with the deps of HornetQ that is integrated.
wdyt?
jeff
[1] https://issues.jboss.org/browse/AS7-5683
[2] https://issues.jboss.org/browse/AS7-5402
[3] https://github.com/projectodd/stilts/pull/8
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=391233
[5]
https://github.com/jbossas/jboss-as/commit/7107c3abcd6220f71380b3602398ed...
[6] https://github.com/infinispan/infinispan/blob/5.2.0.Beta1/parent/pom.xml#...
[7] https://issues.jboss.org/browse/HORNETQ-819
--
- DML
6:21 p.m.
On 10/05/2012 04:33 PM, David M. Lloyd wrote:
This is not the first time a group ID has changed. What you have to
do is:
1. Examine dependency:tree and add exclusions to every project pulling
in Netty in the main POM (this should already have been done, since
*every* artifact should have all its transitives excluded, but people
are getting lazy about this). You may have to run dependency:tree
several times to find them all.
2. Add an enforcer rule to ban the old coordinates.
3. Replace the old dependency with the new one in all modules that
require Netty directly or transitively.
Thanks for the help, David, I followed your advices to clean up the transitive
dependencies and make sure we only depend on a
single Netty version[1]
4. Test!
Jenkins is running the AS7 test suite.
I'm confident for HornetQ as it is the Netty version that is tested in its test
suite.
Infinispan 5.2.0.BETA1 requires the next version of Netty (3.4.6.Final) but it's
better than what is running with now in AS7
(3.2.6.Final). So we should be better
cheers,
jeff
[1] https://github.com/jmesnil/jboss-as/commit/185402610b6e304af946274ff9bcc4...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
5:42 p.m.
On Friday 05 October 2012 09:51 PM, Jeff Mesnil wrote:
On 10/05/2012 04:33 PM, David M. Lloyd wrote:
> This is not the first time a group ID has changed. What you have to do is:
>
> 3. Replace the old dependency with the new one in all modules that
> require Netty directly or transitively.
Thanks for the help, David, I followed your advices to clean up the transitive
dependencies and make sure we only depend on a
single Netty version[1]
[1] https://github.com/jmesnil/jboss-as/commit/185402610b6e304af946274ff9bcc4...
I think we should rename the module too and then scan all the shipped
module.xml files to update the module name to the new name (scanning the
java code too would be a good idea for hardcoded module name, but I
don't think we have any for the netty module). The org.jboss.netty
module was already marked as "private" which means even if changing the
module name to io.netty "breaks" applications which depend on it, it's
reasonable to expect such applications to use the new module name or
better yet package that library within their application.
-Jaikiran
8:46 a.m.
On 10/06/2012 05:42 PM, Jaikiran Pai wrote:
On Friday 05 October 2012 09:51 PM, Jeff Mesnil wrote:
> On 10/05/2012 04:33 PM, David M. Lloyd wrote:
>> This is not the first time a group ID has changed. What you have to do is:
>>
>> 3. Replace the old dependency with the new one in all modules that
>> require Netty directly or transitively.
> Thanks for the help, David, I followed your advices to clean up the transitive
dependencies and make sure we only depend on a
> single Netty version[1]
>
>
> [1]
https://github.com/jmesnil/jboss-as/commit/185402610b6e304af946274ff9bcc4...
>
I think we should rename the module too and then scan all the shipped
module.xml files to update the module name to the new name (scanning the
java code too would be a good idea for hardcoded module name, but I
don't think we have any for the netty module). The org.jboss.netty
module was already marked as "private" which means even if changing the
module name to io.netty "breaks" applications which depend on it, it's
reasonable to expect such applications to use the new module name or
better yet package that library within their application.
I hesitated about this but I preferred to keep the module as it is.
This version of Netty remains compatible with the 3.x releases. The change of groupId has
no repercussion on its API or usage.
It is transparent for modules depending on Netty. All modules depending on
org.jboss.netty:main will continue to work.
However if the 4.x releases of Netty, they do change the packages (to io.netty) and breaks
the API. My preference is to change
the Netty module name when we upgrade to a 4.x version instead.
There is no direct relation between a JBoss module names and the packages or mvn groupId.
If they are different (as in this
case), I find more intuitive to have it mapped to the packages.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
4:36 p.m.
Hi,
If we define newer vesion of com.ning dependancy
(aether-connector-asynchttpclient currently depends to 1.6.5)
<dependency>
<groupId>com.ning</groupId>
<artifactId>async-http-client</artifactId>
<version>1.7.6</version>
</dependency>
problem would be solved, as new version uses io.netty as dependancy
http://mvnrepository.com/artifact/com.ning/async-http-client/1.7.6
--
tomaz
On Fri, Oct 5, 2012 at 4:20 PM, Jeff Mesnil <jmesnil(a)redhat.com> wrote:
Hi guys,
This is of interest for infinispan, web & messaging subsystem and the test
suite.
As a part of upgrading HornetQ to 2.3.O.BETA1 in AS7[1], we also need to
upgrade its dependency to Netty 3.4.5.Final[2].
Inside AS7, the Web subsystem also depends on Netty. Guys, is it ok for
you to upgrade to 3.4.5?
Unfortunately, to move from Netty 3.2.x to Netty 3.4.x, we must also
change its groupId from org.jboss.netty to io.netty.
If I do that, I can no longer build AS7 test suite because of bad
dependencies which requires Netty 3.2.x:
+-org.jboss.as:jboss-as-testsuite:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-build:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-core-model-test:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-model-test:7.2.0.Alpha1-SNAPSHOT
+-org.sonatype.aether:aether-connector-asynchttpclient:1.13.1
+-com.ning:async-http-client:1.6.5
+-org.jboss.netty:netty:3.2.5.Final
and
+-org.jboss.as:jboss-as-testsuite:7.2.0.Alpha1-SNAPSHOT
+-org.projectodd.stilts:stilts-stomp-client:0.1.26
+-org.projectodd.stilts:stilts-stomp-api:0.1.26
+-org.jboss.netty:netty:3.2.1.Final
Since only the test suite depends on Netty 3.2.x, in my PR, I have 2
versions of Netty:
* io.netty Netty 3.4.5.Final => used by AS7 codebase
* org.jboss.netty Netty 3.2.x => used by AS7 test suite
This is ugly but this works...
However, I'd like to reconcile these 2 versions and upgrade everything to
3.4.5.Final
I have submitted patches for Stilts[3] and Aether connector[4] to upgrade
their dependencies to Netty 3.4.x (groupId=io.netty).
Until they release new versions of their components, we are stuck with
Netty 3.2.x.
Another question is about the recent upgrade to Infinispan 5.2.0.BETA1[5].
When I look at this version's POM[6], it depends on
Netty 3.4.6.Final. Shouldn't have Netty been updated at the same time than
Infinispan?
If that's not required to upgrade a component dependencies when the
component is upgraded, I could postpone Netty 3.4.x upgrade.
However some HornetQ bugs requires this version (e.g. for WebSockets
support[7]). I really want to keep the AS7 dependencies in
sync with the deps of HornetQ that is integrated.
wdyt?
jeff
[1] https://issues.jboss.org/browse/AS7-5683
[2] https://issues.jboss.org/browse/AS7-5402
[3] https://github.com/projectodd/stilts/pull/8
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=391233
[5]
https://github.com/jbossas/jboss-as/commit/7107c3abcd6220f71380b3602398ed...
[6]
https://github.com/infinispan/infinispan/blob/5.2.0.Beta1/parent/pom.xml#...
[7] https://issues.jboss.org/browse/HORNETQ-819
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5:13 p.m.
On 10/05/2012 04:20 PM, Jeff Mesnil wrote:
Hi guys,
This is of interest for infinispan, web & messaging subsystem and the test suite.
As a part of upgrading HornetQ to 2.3.O.BETA1 in AS7[1], we also need to upgrade its
dependency to Netty 3.4.5.Final[2].
Inside AS7, the Web subsystem also depends on Netty. Guys, is it ok for you to upgrade to
3.4.5?
for web Weird... I don't know why.
I have a pull request to remove it:
https://github.com/jbossas/jboss-as/pull/3194
Cheers
Jean-Frederic
4223
days inactive
4226
days old
6 comments
5 participants
participants (5)
-
David M. Lloyd -
Jaikiran Pai -
jean-frederic clere -
Jeff Mesnil -
Tomaž Cerar