[jira] [Closed] (TOMEE-794) skinny war support with a standard XML descriptor in the WEB-INF containing all the maven coordinates of jars to add to the classpath

["Romain Manni-Bucau (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TOMEE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Romain Manni-Bucau closed TOMEE-794.
------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.6.0
         Assignee: Romain Manni-Bucau

Closing since jars.txt is in place
                
> 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
>            Assignee: Romain Manni-Bucau
>             Fix For: 1.6.0
>
>
> 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