1 of 1 people found this helpful
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.
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.