OK, I see the point.

The advantage of executing the test in the only existing war is that it is the "deepest" nested context in the ear and it has access to everything else in the application.

But wouldn't it be a nice idea to let the tester decide in which context to run when creating the deployment?

I am thinking about something like a new member "moduleUnderTest" of the @Deployment annotation:

    @Deployment(name="deployment-1", moduleUnderTest="MyOwnWar.war")

    public static Archive<EnterpriseArchive> getCacheServer() throws Exception {

          // Create a deployment that has more than one war, one of which is named "MyOwnWar.war"

          // Test will be running in the context of "MyOwnWar.war"

     }

    @Deployment(name="deployment-1")

    public static Archive<EnterpriseArchive> getCacheServer() throws Exception {

          // Create a deployment that has exactly one war, one of which is named "MyOwnWar.war"

          // Test will be running in the context of "MyOwnWar.war" so that the behaviour is still the same

     }

    @Deployment(name="deployment-1")

    public static Archive<EnterpriseArchive> getCacheServer() throws Exception {

          // Create a deployment that has more than one war, one of which is named "MyOwnWar.war"

          // Test will be running in the context of the new war "test.war" just like no war exists

          // Behaviour changes only in so far as the test would have been aborted before due to multiple wars.

          // Or maybe even still abort with an exception and the moduleUnderTest member must be set because there is no longer a default!

     }

What do you think about this?

Kind regards,

Robert

Hi Aslak,

I played around a bit and finally got a small patch that adds a field "archiveForEnrichment" to @Deployment that allows to specify the archive to be enriched.

I've tested it with an ear and it seems to work for me, i.e. the test is aborted when the value is not set with the current UnsupportedOperationException but works if an archive to be enriched is defined.

So the deployment method would look like this:

    @Deployment(name="deployment-1", archiveForEnrichment="MyOwnWar.war")

    public static Archive<EnterpriseArchive> getCacheServer() throws Exception {

          ...

          return myEar;

     }

If you think that this could be an option I could post a pull request via github.

The patch changes these files:

#       modified:   container/spi/src/main/java/org/jboss/arquillian/container/spi/client/deployment/DeploymentDescription.java

#       modified:   container/test-api/src/main/java/org/jboss/arquillian/container/test/api/Deployment.java

#       modified:   container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/client/deployment/AnnotationDeploymentScenarioGenerator.java

#       modified:   container/test-spi/src/main/java/org/jboss/arquillian/container/test/spi/TestDeployment.java

#       modified:   protocols/servlet/src/main/java/org/jboss/arquillian/protocol/servlet/v_3/ServletProtocolDeploymentPackager.java

Kind regards,

Robert

Ah, ok.

I did not think about this case as we assemble our ears using our own build process and create the Deployments using ShrinkWrap.createFromZipFile() so that there are no UUIDs in the archive names.

(Additionally we add some fragments to do the database setup when the application is launched much the same way arquillian adds its web fragment;-) )

But you are perfectly right and I no longer think that my proposal is a good idea:-)

I you still like to take a short look at it, you can check https://github.com/robertpanzer/arquillian-core/commit/a39a45c73bd4daedfcf4cd2e8f5fe120fd689d8a

As I am still interested in getting this scenario to work maybe I can do some work for it.

Did you think of adding something like a marker file to the archive in "Testable.archiveToTest()"?

I guess that should be placed into the arquillian-test-api into the same package as @ArquillianResource?

Hi Aslak,

using your proposed approach it was even simpler to realize that in the arquillian code.

I used your proposed API with Testable.archiveToTest() as it really seems to be a good way to me.

Could you take a look at https://github.com/robertpanzer/arquillian-core/commit/010e04682a78a71736f32996c816dfc9f2c3378f ?

Or do you prefer that I directly provide a pull request?

Thanks and kind regards,

Robert

No problem, I got enough to do as well.

I've taken a look at the code again and I think it would be best to have a org.jboss.arquillian.container.test.spi.client.deployment.ProtocolArchiveProcessor that scans the archives for the marker file and sets the archive on the TestDeployment.

So this processor should probably go into arquillian-protocol-servlet artefact as well, right?

Hi Aslak,

I know, the processor stuff was the wrong way.

I added a new commit, where the whole marker stuff is concentrated in Testable and identification of the archive to test is moved to TestDeployment.

Could you please take a look at it?

https://github.com/robertpanzer/arquillian-core/compare/MulitpleWarsWithMarker

Kind regards,

Robert

Hi Aslak,

I just posted a pull request for this:

https://github.com/arquillian/arquillian-core/pull/36

Kind regards,

Robert

Just in case someone has the same problem and found this thread:

Pull Request has been merged and is part of arquillian-core 1.0.2.Final.