Proposal for @Deployment method returning JavaArchive[]

[xavi.arias.segui]

Hello,

After so many time spent with JUnit, Arquillian and ShrinkWrap, I think there are some issues that need to be addressed in order to save time to API users. The biggest headaches I have found when using those APIs are:

• Injection of @PersistenceContexts, CDI beans with @Inject and @EJBs in test classes.
• CDI scope management when some libraries must not have beans.xml.
• JPA test files (i.e. with auto-creation of JPA tables before test execution) that need to replace the production ones.

When the module to test is an EAR or a WAR, Maven resolver is very helpful to manage the dependency burden, but when I need to test an EJB module, I need to build myself an EAR or WAR and problems appear.

Since Arquillian deployer already builds a WAR module to run a test, why not allow @Deployment methods to return a JavaArchive[] so Arquillian can build the test module itself by placing the JARs and configure the test class in a simpler manner?

Regards,

Xavier

[kpiwko]

Hi Xavier,

Many thanks for the feedback! Can you please elaborate more on "but when I need to test an EJB module, I need to build myself an EAR or WAR and problems appear."? We can for sure bring improvements into ShrinkWrap and ShrinkWrap Resolvers projects but more details would be needed.

What are the issues with JPA files? Do you want to create another persistence.xml based on existing? Or build it somehow automatically? What are the problems with injection?

As for returning JavaArchive[], how would Arquillian Deployer figure out what you actually want it to build? My guess is that more convenient might rather be to create EJBArchive extends JavaArchive, which might represent some syntax sugar on top of JavaArchive.

Cheers,

Karel

[xavi.arias.segui]

Hi Karel,

Improvements might go in the direction of creating an API for dummies, so if I add a persistence.xml file to a WAR file, there could be a specific method that puts it on the right place WEB-INF/classes/META-INF instead of letting the API user mess with the subtle details of the specification version. The same for beans.xml, ejb-jar.xml, etc.; a bit of syntax sugar to handle specific needs would save huge amounts of coding time. Actually I spend more time trying to use Arquillian and ShrinkWrap than coding itself! And this is after hours spent learning how to use resolvers, importers, exporters, descriptors, etc.

Imagine the use case I want to test an EJB module with a complex dependency graph, so I need to use Maven resolver to handle it.

The main problems I have found when trying to do this are that resolved EJB modules (in the canonic form groupId:artifactId:ejb:version) come with .ejb extension (since they don't exist in the JEE world, .ejb files are ignored when deployed). Also, getting the same packaging type for every dependency (JAR by default). How am I supposed to build an EAR if I don't know if a dependency is an EJB module or a Library? If I build a WAR to simplify this an put everything in the lib folder, then I get unresolved EJB references since EJB visibility is different between WARs and  EARs (?)

The proposal for returning a JavaArchive[] is letting Arquillian to build the test deployment properly. In the same manner that builds a a deployable module to test a JavaArchive, it could build it for a set of JavaArchives, whether an EAR or a WAR, to help the programmer coding time. The previous use case would be done by resolving an EJB module with transitivity, eventually update some JPA or CDI config files, and return the archive list. Voilà!

For JPA config files, I do as you say, create another persistence.xml based on existing one in the JPA module and update its properties to set the auto-create tables and logging level. The drawback is that @PersistenceContexts are not injected to test classes! But if I put the persistence.xml file into the WAR's WEB-INF/classes/META-INF folder, entities are not scanned... and I get desperate

Another big problem is the lack of logging information. Right now I am tryning to deploy a resolved EAR and I get an "IllegalArgumentException: ArquillianServletRunner not found. Could not determine ContextRoot from ProtocolMetadata..." exception without any other information, and this is right after a "INFO: module-x.x.x-SNAPSHOT was successfully deployed in 14 718 milliseconds."

I wish I had more time to spend in the project since I think it is a very good API.

Regards,

Xavier