[ https://issues.jboss.org/browse/SHRINKWRAP-396?page=com.atlassian.jira.pl... ] Craig Ringer updated SHRINKWRAP-396: ------------------------------------ Description: 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: {code} BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class) .from(new File("src/main/webapp/WEB-INF/beans.xml")); PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class) .from(new File("src/main/resources/META-INF/persistence.xml")); WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war") .addPackage(Demo.class.getPackage()) .addAsWebInfResource(new StringAsset(beansXml.exportAsString()), "beans.xml") .addAsResource(new StringAsset(persistenceXml.exportAsString()), "META-INF/persistence.xml"); {code} 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: {code} BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class).fromDefaultLocation(); PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class).fromDefaultLocation(); WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war") .addPackage(Demo.class.getPackage()) .addDescriptor(beansXml) .addDescriptor(persistenceXml); {code} 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: {code} MavenDependencyResolver mvn = DependencyResolvers.use(MavenDependencyResolver.class) .configureFrom("pom.xml"); BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class).byPom(mvn); PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class).byPom(mvn); {code} ... or ...: {code} MavenDependencyResolver mvn = DependencyResolvers.use(MavenDependencyResolver.class) .configureFrom("pom.xml"); BeansDescriptor beansXml = mvn.importDescriptor(BeansDescriptor.class); PersistenceDescriptor persistenceXml = mvn.importDescriptor(PersistenceDescriptor.class); {code} 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: {code} String defaultPathInArchive(Archive archive) {code} 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. was: 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: {code} BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class) .from(new File("src/main/webapp/WEB-INF/beans.xml")); PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class) .from(new File("src/main/resources/META-INF/persistence.xml")); WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war") .addPackage(Demo.class.getPackage()) .addAsWebInfResource(new StringAsset(beansXml.exportAsString()), "beans.xml") .addAsResource(new StringAsset(persistenceXml.exportAsString()), "META-INF/persistence.xml"); {code} 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: {code} BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class).fromDefaultLocation(); PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class).fromDefaultLocation(); WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war") .addPackage(Demo.class.getPackage()) .addDescriptor(beansXml) .addDescriptor(persistenceXml); {code} 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: {code} MavenDependencyResolver mvn = DependencyResolvers.use(MavenDependencyResolver.class) .configureFrom("pom.xml"); BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class).byPom(mvn); PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class).byPom(mvn); {code} ... or ...: {code} MavenDependencyResolver mvn = DependencyResolvers.use(MavenDependencyResolver.class) .configureFrom("pom.xml"); BeansDescriptor beansXml = mvn.importDescriptor(BeansDescriptor.class); PersistenceDescriptor persistenceXml = mvn.importDescriptor(PersistenceDescriptor.class); {code} 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: {code} String defaultPathInArchive(Archive archive) {code} 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. Forum Reference: https://community.jboss.org/message/729492 (was: https://community.jboss.org/message/729492) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira