[
https://issues.apache.org/jira/browse/TOMEE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603518#comment-13603518
]
Alan Cabrera commented on TOMEE-794:
------------------------------------
Changing the format to XML would do the trick. This is what was originally
proposed by James.
Not sure what you mean by "that's far more powerful since you can add things
you don't know (once again if you don't want it inhibit it)" but I will say
modifying the contents of a WAR by modifying the contents of the jars, but
keeping the version the same, is an anti-pattern that definitely diminishes the
credibility of the proposal.
With that said, if we can agree to use XML, then I'm happy to work on the
optional signature bit. We could have an xml file such as
<jars>
<jar uri="mvn:org.apache.camel:camel-core:2.8.3" />
</jars>
then you are not blocked on my effort.
> 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
