On 09/21/2012 04:14 PM, Paul Robinson wrote:
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?
I looked at the question of whether any released jboss-as-arquillian container can be used with the current server code base. I found API incompatibilities, which could be overcome by adding deprecated APIs the delegate to the server, but also semantic incompatibilities which cannot be overcome. The released arq containers check for a condition that used to be an error in 7.1.2 but is now the correct behaviour.

I'll look at this a little more (https://issues.jboss.org/browse/AS7-5613) and see if I can improve stability for the future.

For the time being I see no alternative but using a SNAPSHOT of the ARQ container or releasing your own fork of it.   



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?
Sorry, I meant 7.1.2.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

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@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@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)


-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx