[
https://issues.apache.org/jira/browse/TOMEE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13602607#comment-13602607
]
james strachan commented on TOMEE-794:
--------------------------------------
A flat file of maven coordinates per line is fine too really.
I'm not sure what the "if mvn is not available" means. You don't need a maven
installation to be able to resolve a set of maven coordinates with a list of
maven repositories to be able to download jars and cache them locally.
"Maven coordinates" or GAV is just the term for the group Id / artifact ID /
version ID naming convention to find jars inside maven repositories. Maven
repositories are just HTTP websites using a naming convention. Its got nothing
to do with requiring maven build software at runtime.
e.g. given the standard central maven repo: http://repo2.maven.org/maven2 and
the coordinates org.apache.camel/camel-core/2.10.4 its trivial to construct a
java.net.URL for
http://repo2.maven.org/maven2/org/apache/camel/camel-core/2.10.4/camel-core-2.10.4.jar
without maven any software at all - just 1 line of Java code using standard
JDK libraries.
There are various utility libraries that will scan multiple maven repos & do
caching and whatnot which folks could use at runtime (e.g. pax-mvn-url or
aether) but its not really required really
> 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
