[
https://issues.apache.org/jira/browse/TOMEE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603470#comment-13603470
]
Romain Manni-Bucau commented on TOMEE-794:
------------------------------------------
foo#hash? but i hate it and really think it is useless to sign anything in this
case so i prefer the option of deactivating it if you have such a constraint.
You speak about skinny wars but that's far more powerful since you can add
things you don't know (once again if you don't want it inhibit it)
> 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
