Does JBossTS need to use the same arquillian container version as is included with the latest AS? I'm no Arquillian expert, but it seems like if that's required something has gone wrong with our Arquillian integration. Seems like the idea would be to make these containers forward compatible. Apologies if I'm all wet here. On 9/17/12 10:12 AM, Paul Robinson wrote: > All, > > JBoss transactions uses Arquillian for some of the project tests. > Therefore JBossTS has a dependency on AS7 (for the Arquillian container > dependency), but as AS7 consumes JBossTS, the target AS7 version is not > available when we do the release of JBossTS. We get around this at the > moment by referencing a SNAPSHOT version of AS7 in the Arquillian > container dependency. However, this does mean that our release will > reference the SNAPSHOT dependency. > > This must be a common issue that other projects have. I was wondering > what the accepted pattern was to solve this issue? > > Paul. > > -- > Paul Robinson > Web service transactions lead > paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com> > > JBoss, a Division of Red Hat > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson > (USA), Charlie Peters (USA) > > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

All, We were thinking of just releasing with jboss-as.version set to the SNAPSHOT of the target AS7 release and then overriding this property if/when the tests are ran against the final release, by passing -Djboss-as.version=<final version> to the build command line. Unless anyone can point out a problem with this approach, or suggest an improvement, we'll just go with that. Paul. On 18 Sep 2012, at 09:55, Paul Robinson <paul.robinson(a)redhat.com&gt; wrote: > Brian, > > I don't think forwards compatibility can be guaranteed. We've had a few problems in the past where the the jboss-as-arquillian-container-managed dependency was set to a different version of AS7 to that which we were testing against. > > Here's a specific example: https://issues.jboss.org/browse/JBTM-1243 and https://github.com/jbosstm/quickstart/pull/18/files for the fix. In this example we were using the jboss-javaee-6.0-with-tools bom to get the jboss-as-arquillian-container-managed dependency version. This bom set the version to 7.1.1.Final, which failed to work with 7.2.0.Alpha1-SNAPSHOT. So, in this case we would need to match up the releases. > > I don't recall the specifics of other occasions, but it's certainly happened to us a few times. > > Paul. > > On 17 Sep 2012, at 16:24, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > >> Does JBossTS need to use the same arquillian container version as is >> included with the latest AS? I'm no Arquillian expert, but it seems like >> if that's required something has gone wrong with our Arquillian >> integration. Seems like the idea would be to make these containers >> forward compatible. >> >> Apologies if I'm all wet here. >> >> On 9/17/12 10:12 AM, Paul Robinson wrote: >>> All, >>> >>> JBoss transactions uses Arquillian for some of the project tests. >>> Therefore JBossTS has a dependency on AS7 (for the Arquillian container >>> dependency), but as AS7 consumes JBossTS, the target AS7 version is not >>> available when we do the release of JBossTS. We get around this at the >>> moment by referencing a SNAPSHOT version of AS7 in the Arquillian >>> container dependency. However, this does mean that our release will >>> reference the SNAPSHOT dependency. >>> >>> This must be a common issue that other projects have. I was wondering >>> what the accepted pattern was to solve this issue? >>> >>> Paul. >>> >>> -- >>> Paul Robinson >>> Web service transactions lead >>> paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com> >>> >>> JBoss, a Division of Red Hat >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson >>> (USA), Charlie Peters (USA) >>> >>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >> >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > -- > Paul Robinson > Web service transactions lead > paul.robinson(a)redhat.com > > JBoss, a Division of Red Hat > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson > (USA), Charlie Peters (USA) > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

No problem, We're happy with this workaround. Just wanted to make sure there wasn't a better solution, as I'm sure other teams are having the same problem. Thanks, Paul On 20 Sep 2012, at 16:21, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > Sorry, Paul, I didn't respond yesterday. Your workaround sounds reasonable to me. > > I think the arq containers should strive to be forward compatible and if they frequently aren't that's not good. But "strive to be" and "infrequently aren't" don't really cut it for your use case, so you need some sort of solution like the one you propose. > > On 9/20/12 6:59 AM, Paul Robinson wrote: >> All, >> >> We were thinking of just releasing with jboss-as.version set to the SNAPSHOT of the target AS7 release and then overriding this property if/when the tests are ran against the final release, by passing -Djboss-as.version=<final version> to the build command line. >> >> Unless anyone can point out a problem with this approach, or suggest an improvement, we'll just go with that. >> >> Paul. >> >> On 18 Sep 2012, at 09:55, Paul Robinson <paul.robinson(a)redhat.com&gt; wrote: >> >>> Brian, >>> >>> I don't think forwards compatibility can be guaranteed. We've had a few problems in the past where the the jboss-as-arquillian-container-managed dependency was set to a different version of AS7 to that which we were testing against. >>> >>> Here's a specific example: https://issues.jboss.org/browse/JBTM-1243 and https://github.com/jbosstm/quickstart/pull/18/files for the fix. In this example we were using the jboss-javaee-6.0-with-tools bom to get the jboss-as-arquillian-container-managed dependency version. This bom set the version to 7.1.1.Final, which failed to work with 7.2.0.Alpha1-SNAPSHOT. So, in this case we would need to match up the releases. >>> >>> I don't recall the specifics of other occasions, but it's certainly happened to us a few times. >>> >>> Paul. >>> >>> On 17 Sep 2012, at 16:24, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> Does JBossTS need to use the same arquillian container version as is >>>> included with the latest AS? I'm no Arquillian expert, but it seems like >>>> if that's required something has gone wrong with our Arquillian >>>> integration. Seems like the idea would be to make these containers >>>> forward compatible. >>>> >>>> Apologies if I'm all wet here. >>>> >>>> On 9/17/12 10:12 AM, Paul Robinson wrote: >>>>> All, >>>>> >>>>> JBoss transactions uses Arquillian for some of the project tests. >>>>> Therefore JBossTS has a dependency on AS7 (for the Arquillian container >>>>> dependency), but as AS7 consumes JBossTS, the target AS7 version is not >>>>> available when we do the release of JBossTS. We get around this at the >>>>> moment by referencing a SNAPSHOT version of AS7 in the Arquillian >>>>> container dependency. However, this does mean that our release will >>>>> reference the SNAPSHOT dependency. >>>>> >>>>> This must be a common issue that other projects have. I was wondering >>>>> what the accepted pattern was to solve this issue? >>>>> >>>>> Paul. >>>>> >>>>> -- >>>>> Paul Robinson >>>>> Web service transactions lead >>>>> paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com> >>>>> >>>>> JBoss, a Division of Red Hat >>>>> Registered in England and Wales under Company Registration No. 03798903 >>>>> Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson >>>>> (USA), Charlie Peters (USA) >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>> >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Principal Software Engineer >>>> JBoss by Red Hat >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> -- >>> Paul Robinson >>> Web service transactions lead >>> paul.robinson(a)redhat.com >>> >>> JBoss, a Division of Red Hat >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson >>> (USA), Charlie Peters (USA) >>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > > > -- > Brian Stansberry > Principal Software Engineer > JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Did you try 7.1.2? There was a "one-time" problem with the protocol. On Sep 20, 2012, at 10:31 AM, Paul Robinson <probinso(a)redhat.com&gt; wrote: > No problem, > > We're happy with this workaround. Just wanted to make sure there wasn't a better solution, as I'm sure other teams are having the same problem. > > Thanks, > > Paul > > On 20 Sep 2012, at 16:21, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > >> Sorry, Paul, I didn't respond yesterday. Your workaround sounds reasonable to me. >> >> I think the arq containers should strive to be forward compatible and if they frequently aren't that's not good. But "strive to be" and "infrequently aren't" don't really cut it for your use case, so you need some sort of solution like the one you propose. >> >> On 9/20/12 6:59 AM, Paul Robinson wrote: >>> All, >>> >>> We were thinking of just releasing with jboss-as.version set to the SNAPSHOT of the target AS7 release and then overriding this property if/when the tests are ran against the final release, by passing -Djboss-as.version=<final version> to the build command line. >>> >>> Unless anyone can point out a problem with this approach, or suggest an improvement, we'll just go with that. >>> >>> Paul. >>> >>> On 18 Sep 2012, at 09:55, Paul Robinson <paul.robinson(a)redhat.com&gt; wrote: >>> >>>> Brian, >>>> >>>> I don't think forwards compatibility can be guaranteed. We've had a few problems in the past where the the jboss-as-arquillian-container-managed dependency was set to a different version of AS7 to that which we were testing against. >>>> >>>> Here's a specific example: https://issues.jboss.org/browse/JBTM-1243 and https://github.com/jbosstm/quickstart/pull/18/files for the fix. In this example we were using the jboss-javaee-6.0-with-tools bom to get the jboss-as-arquillian-container-managed dependency version. This bom set the version to 7.1.1.Final, which failed to work with 7.2.0.Alpha1-SNAPSHOT. So, in this case we would need to match up the releases. >>>> >>>> I don't recall the specifics of other occasions, but it's certainly happened to us a few times. >>>> >>>> Paul. >>>> >>>> On 17 Sep 2012, at 16:24, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> Does JBossTS need to use the same arquillian container version as is >>>>> included with the latest AS? I'm no Arquillian expert, but it seems like >>>>> if that's required something has gone wrong with our Arquillian >>>>> integration. Seems like the idea would be to make these containers >>>>> forward compatible. >>>>> >>>>> Apologies if I'm all wet here. >>>>> >>>>> On 9/17/12 10:12 AM, Paul Robinson wrote: >>>>>> All, >>>>>> >>>>>> JBoss transactions uses Arquillian for some of the project tests. >>>>>> Therefore JBossTS has a dependency on AS7 (for the Arquillian container >>>>>> dependency), but as AS7 consumes JBossTS, the target AS7 version is not >>>>>> available when we do the release of JBossTS. We get around this at the >>>>>> moment by referencing a SNAPSHOT version of AS7 in the Arquillian >>>>>> container dependency. However, this does mean that our release will >>>>>> reference the SNAPSHOT dependency. >>>>>> >>>>>> This must be a common issue that other projects have. I was wondering >>>>>> what the accepted pattern was to solve this issue? >>>>>> >>>>>> Paul. >>>>>> >>>>>> -- >>>>>> Paul Robinson >>>>>> Web service transactions lead >>>>>> paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com> >>>>>> >>>>>> JBoss, a Division of Red Hat >>>>>> Registered in England and Wales under Company Registration No. 03798903 >>>>>> Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson >>>>>> (USA), Charlie Peters (USA) >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jboss-as7-dev mailing list >>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Principal Software Engineer >>>>> JBoss by Red Hat >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> -- >>>> Paul Robinson >>>> Web service transactions lead >>>> paul.robinson(a)redhat.com >>>> >>>> JBoss, a Division of Red Hat >>>> Registered in England and Wales under Company Registration No. 03798903 >>>> Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson >>>> (USA), Charlie Peters (USA) >>>> >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >> >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Thomas, I'm a bit confused by you're email... On 21 Sep 2012, at 12:17, Thomas Diesler wrote: > I looked into this and it turns out that it cannot get fixed easily. Do you mean, specifically for this release (7.2.0), or in general that we always need to run the same version of the container dependency and the target server?

> > For background info: We used to have the ARQ server side components > available as a subsystem. This is the thing that receives the remote > JMX invocation, runs JUnit on the server and reports the test results > back. It was then decided to remove that subsystem and provide these > services dynamically as part of the ARQ TestSuite#Start lifecycle. > The code that was contained in the ARQ subsytem is now assembled on > the client side and deployed to AS as the arquillian-service deployment. > > This ARQ deployment has a few dependencies on the server components > and the OSGi subsystem. The dependency on OSGi is necessary because > test class loading works differently when the test case is contained > in a bundle. Additionally the osgi subsystem needs to be bootstrapped > if there is a test deployment that needs it. > > The API incompatibilities could be overcome but there is also a > fundamental semantic change with respect to 7.2.1.Final. We now have > a Module attached to the DU for a successfully resolved bundle. This > however is an error condition in the 7.2.1.Final ARQ service. Do you mean 7.2.1.Final?

> > I propose to release a recent snapshot of the jboss-as/arquillian > maven modules. That 3rd party can use to run their tests against the > 7.2.x code base. > > cheers > --thomas > > On 09/17/2012 05:12 PM, Paul Robinson wrote: >> All, >> >> JBoss transactions uses Arquillian for some of the project tests. >> Therefore JBossTS has a dependency on AS7 (for the Arquillian >> container dependency), but as AS7 consumes JBossTS, the target AS7 >> version is not available when we do the release of JBossTS. We get >> around this at the moment by referencing a SNAPSHOT version of AS7 >> in the Arquillian container dependency. However, this does mean that >> our release will reference the SNAPSHOT dependency. >> >> This must be a common issue that other projects have. I was >> wondering what the accepted pattern was to solve this issue? >> >> Paul. >> >> -- >> Paul Robinson >> Web service transactions lead >> paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com> >> >> JBoss, a Division of Red Hat >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson >> (USA), Charlie Peters (USA) >> >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > -- > xxxxxxxxxxxxxxxxxxxxxxxxxxxx > Thomas Diesler > JBoss OSGi Lead > JBoss, a division of Red Hat > xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- Paul Robinson Web Service Transactions Lead paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com> JBoss, a Division of Red Hat Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA)