[
https://issues.apache.org/jira/browse/TOMEE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603939#comment-13603939
]
Alan Cabrera commented on TOMEE-794:
------------------------------------
I wish we could have inline comments here. :)
My reference to XML was in reference to the format of the skinny file. It was
my understanding that format of the URI would be the Mvn URI from the PAX
project, http://team.ops4j.org/wiki/display/paxurl/Mvn+Protocol. There is no
mechanism to add a '#' character at the end. Also, it is an extremely bad
practice to store a hash without also including how it was generated. I had
envisioned that the hashed jars would be recored thusly:
<jars>
<jar uri="mvn:org.apache.camel/camel-core/2.8.3">
<sha1Digest>fcav7ShIG6i86xPepmitOVo4vWY=</sha1Digest>
</jar>
</jars>
un-hashed jars would have the skinny file formatted as mentioned above.
RE: adding things that you don't know: I remain unconvinced. It definitely
speaks to the enduring myth of the utility of ultimate flexibility.
Unfortunately, Jira comments are not the proper forum for a dialog to discuss
this matter. Maybe we can continue on the mailing list?
> skinny war support with a standard XML descriptor in the WEB-INF containing
> all the maven coordinates of jars to add to the classpath
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TOMEE-794
> URL: https://issues.apache.org/jira/browse/TOMEE-794
> Project: TomEE
> Issue Type: New Feature
> Reporter: james strachan
>
> Skinny WARs rock. The Resin folks came up with the pomegranate spec a while
> ago.
> http://blog.caucho.com/2009/08/05/pomegranate-draft/
> which seems pretty reasonable. The idea is to have an XML file with the maven
> coordinates inside the WEB-INF/pom.xml file; then we don't waste disk and
> time chucking the same 20Mb of stuff inside WARs only to then unexpand the
> WAR and take them out again.
> I created something similar in OSGi land
> http://fuse.fusesource.org/bundle/overview.html
> The main thing folks want to do is reuse their pom.xml for their project; but
> then they want to include/exclude some things in the WAR (e.g. excluding
> provided scope), or include optional things or not etc.
> With FAB I went with the approach of extra manifest headers to help decide
> when to hide things / include optional things etc. Then at runtime we'd
> download the pom and walk the pom dependencies and whatnot.
> I think a much simpler approach though is doing all this choosing & decision
> making at build time; then any configuration of these choices is just maven
> plugin configuration.
> i.e. have a maven plugin which at build time generates the XML file (e.g.
> WEB-INF/pom.xml) by walking all the transitive dependencies, excluding things
> (e.g. optional / provided stuff) and expanding any maven property values and
> whatnot.
> So that at runtime, the embedded WEB-INF/pom.xml contains a flat list of
> everything required to startup the WAR. i.e. its a 'post processed pom.xml' -
> with no transitive dependencies, no property values, no parent poms etc. So
> its a massive subset of what kind of pom is allowed. (For this reason its
> tempting to use a different XML format to emphasis this subset; I guess worst
> case we could use a different XML namespace or XSD?)
> This means that at runtime its really fast; since it really is just a list of
> maven coordinates to add to the skinny WAR which no maven/aether
> infrastructure is required at all - just a little parse of the XML would do
> to get the maven coordinates.
> In terms of adding the skinny wars to the classpath; it would be good if they
> were downloaded and stored locally within the server's directory tree - using
> a maven repo style directory tree structure - so that folks could deploy some
> apps (they'd download jars on the fly from maven repos). Then they could take
> a tarball of a server and know all the required jars are local. Similarly
> folks can make a 'tomcat distro generation' maven plugin to pre-populate the
> containers's maven repo with stuff it is gonna need.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
