[
http://jira.codehaus.org/browse/MWAR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86336
]
Cliff Resnick commented on MWAR-9:
----------------------------------
After searching, I have not found any resolution for this problem. Is there one?
In the meantime, for my own purposes I have altered the plugin to so that
"optional=true" works recursively, simply by checking for existence of optional
artifacts in the dependency trail of all resolved artifacts.
This finally gives me what I consider desired (at least tolerable) behavior:
scope:compile = classpath and WEB-INF/lib (though cp is not necessary, it
doesn't hurt)
scope:provided = no classpath, no WEB-INF/lib
optional = transitively resolved artifacts on classpath, no WEB-INF/lib
I know this is just furthering a hack, but I'm not sure how else to do it since
there seems to be an inherent containment issue where war shouldn't know about
the ear. Where I work, we use what we consider a "best practice" approach where
ear, war, sar, etc. projects are siblings, with a parent "server" pom project
providing all container-based scope=provided dependencies. This primarily
filters all container-provided compile dependencies used by core components,
greatly simplifying the poms of the container-based components. I know it may
be a stretch, but perhaps such a "container" parent project could be somehow
formalized, at least to provided a way to formally put the ear before the war?
Just a thought...
> WAR plugin should support minimal WARs for inclusion within an EAR
> ------------------------------------------------------------------
>
> Key: MWAR-9
> URL: http://jira.codehaus.org/browse/MWAR-9
> Project: Maven 2.x War Plugin
> Issue Type: Improvement
> Reporter: Mike Perham
> Assigned To: Stephane Nicoll
>
> I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my
> deps. This is fine for a default but maven should also support "skeleton"
> WARs which will be packaged within an EAR. We have EARs which package 3-4
> WARs each and to have the deps duplicated within each WAR means we cannot
> have shared data (since the classes are loaded within each WAR's classloader,
> rather than by the parent EAR's classloader). It also means 80MB EARs! :-)
> It seems like two things need to happen:
> 1) Add a "skeleton" flag which prevents copying any dependencies to
> WEB-INF/lib.
> 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which
> lists the relative locations of the dependencies within the parent EAR.
> Fabrice has basically the same idea written down here. Starting with "- for
> a War..." :
> http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
