[shrinkwrap-issues] [JBoss JIRA] (SHRINKWRAP-396) Automatic paths for descriptor import from project and packaging into archives
Craig Ringer (JIRA)
jira-events at lists.jboss.org
Fri Apr 13 08:07:47 EDT 2012
[ https://issues.jboss.org/browse/SHRINKWRAP-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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.
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:
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");
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:
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);
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:
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);
... or ...:
MavenDependencyResolver mvn = DependencyResolvers.use(MavenDependencyResolver.class)
.configureFrom("pom.xml");
BeansDescriptor beansXml = mvn.importDescriptor(BeansDescriptor.class);
PersistenceDescriptor persistenceXml = mvn.importDescriptor(PersistenceDescriptor.class);
Opinions?
Forum Reference: https://community.jboss.org/message/729492 (was: https://community.jboss.org/message/729492)
After examining the code in question, updated rationale with details
> Automatic paths for descriptor import from project and packaging into archives
> ------------------------------------------------------------------------------
>
> Key: SHRINKWRAP-396
> URL: https://issues.jboss.org/browse/SHRINKWRAP-396
> Project: ShrinkWrap
> Issue Type: Feature Request
> Components: ext-descriptors
> Environment: 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
> Arquillian 1.0.0.Final
> Reporter: Craig Ringer
> Labels: arquillian, descriptor, maven, shrinkwrap
>
> 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.
--
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
More information about the shrinkwrap-issues
mailing list