[ 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