[
https://issues.apache.org/jira/browse/TOMEE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603425#comment-13603425
]
Alan Cabrera commented on TOMEE-794:
------------------------------------
1) To be sure not all users sign their WARs but those who do take signing very,
very, seriously.
2) Yes, a change to the skinny file will change the WAR's signature. However,
changes to the jars that are referenced in the skinny file do not change the
WAR's signature. This is why we must include hashes of the contents of the
WARs in the skinny file. At least make such hashes optional.
> 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
