Type: Feature Request
Status: Open (View Workflow)
Affects Version/s: None
Fix Version/s: None
Linux wallace 3.0.0-14-generic-pae #23-Ubuntu SMP Mon Nov 21 22:07:10 UTC 2011 i686 i686 i386 GNU/Linux
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode)
JBoss AS 7.1.1.Final
Using BeansDescriptor, PersistenceDescriptor, etc is currently a bit more verbose and error prone than it really needs to be.
These descriptors have very well established locations in the source tree in standard Maven structured projects, and absolutely fixed locations within archives of a given type. The descriptors module should know those locations and be able to use them unless overridden.
Current code for loading and using beans.xml and persistence.xml is currently pretty verbose and repeats paths that're fixed by strong convention and/or standards requirements:
The paths to beans.xml and persistence.xml are dependent on the archive type but otherwise absolutely fixed by convention. As such, it should be possible to write something like:
In the above, `.fromDefaultLocation()' will pluck the descriptor from the standard spot in the Maven source tree, and the .addDescriptor(...)' method will pass the archive type to an -impl descriptor method that returns the appropriate archive path for that descriptor in that archive type, eg /WEB-INF/beans.xml for a BeansDescriptor in a WebArchive, /WEB-INF/classes/META-INF/persistence.xml for a PersistneceDescriptor in a WebArchive, /META-INF/persistence.xml for a PersistenceArchive in a JavaArchive, etc.
Because the location of beans.xml in the source tree varies based on the pom.xml <packaging/> directive, it might be necessary to integrate with the maven resolver plugin to get <packaging/> info from the pom, producing something like:
... or ...:
This isn't trivial to do because each part of ShrinkWrap and each module is so loosely connected. The ShrinkWrap descriptors API doesn't depend on or reference the ShrinkWrap API at all, so the Descriptors module can't provide any implementations of org.jboss.shrinkwrap.api.asset.Asset . ShrinkWrap proper doesn't know about Descriptors so it can't provide an addDescriptor(Descriptor) method.
It's my opinion that the Descriptor interface its self needs to be packaged in ShrinkWrap's API so it can implement Asset and be accepted by a new 'addDescriptor(...)" method on Archive, and ShrinkWrap Descriptors' API needs to depend on the ShrinkWrap API to get access to the Descriptor interface. A method can then be added to Descriptor like:
so each descriptor implementation can report a default archive path, eg PersistenceDescriptor would return "/META-INF/persistence.xml" for a JavaArchive and "/WEB-INF/classes/META-INF/persistence.xml" for a WebArchive; BeansDescriptor would report "/WEB-INF/beans.xml" for a WebArchive and "/META-INF/beans.xml" for a JavaArchive, etc.
It might well be decided that the convenience of a dedicted Archive.addDescriptor(...) method isn't worth adding the interdependency. If so, though, I have no idea how it'd be possible for a descriptor to indicate what path it should live at, which IMO would be a huge limitation for the usability of a library that's used largely for testing, where usability is critical. Archives need to know about descriptors, and/or descriptors need to know about archives.
That still doesn't answer the other side, how to find the path in the source tree to import descriptors from. That probably requires knowledge of the Maven project structure (for Maven projects) so the Maven Dependency Resolver plugin might need to know about descriptors. I don't think descriptors need to know about (depend on) the maven plugin, though; the maven plugin would just work out the path then use Descriptors.importAs(...).from(...) and return the result.