[jira] Commented: (MEAR-17) Jar files packed in the EAR file should also be added to application.xml or manifest.mf
[ http://jira.codehaus.org/browse/MEAR-17?page=comments#action_61995 ] Mark Chesney commented on MEAR-17: -- I thought Maven was supposed to "provide guidelines for best practices development". This new property really seems like a hack. The entire Chapter 8 in the J2EE 1.4 spec (See http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf) is dedicated to J2EE assembly and packaging use cases which are required to be supported by any J2EE container. To acheive these use cases with Maven requires redundant, hackish, fragile configuration. Can we look at the big picture and set a Maven standard for J2EE packaging which covers these use cases? > Jar files packed in the EAR file should also be added to application.xml or > manifest.mf > --- > > Key: MEAR-17 > URL: http://jira.codehaus.org/browse/MEAR-17 > Project: Maven 2.x Ear Plugin > Type: Improvement > Reporter: Kristoffer Peterhäesel > Assignee: Stephane Nicoll > Fix For: 2.2 > > > While attempting to package an EAR for deployment on JBoss I have come across > a (for me) major issue with the way this module works. > The issue is that there are a lot dependency jars included by default. That > by itself isn't the problem. The problem is there is no way to include it in > the classpath without defining all the dependencies again in the pom.xml for > the EAR. > In an ideal world (for me) the jars would be an easy way to add the jars to > the classpath since I want to include all I need in the EAR to make it as > easy as possible to set up a depoyment environment. > There are really two options for how to do that. Either the jar files are > added to the generated Manifest.MF file or else there should be a simple > option to include all packed jar files to the application.xml. Both should > (AFAIK) work in any standard-compliant container. > The option of putting all the jar files in APP-INF/lib only works on Weblogic. -- 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
[jira] Commented: (MEJB-7) Transitive Classpath not written to the manifest
[ http://jira.codehaus.org/browse/MEJB-7?page=comments#action_61994 ] Mark Chesney commented on MEJB-7: - Have you configured the archive.manifest.addClasspath property? maven-ejb-plugin true > Transitive Classpath not written to the manifest > > > Key: MEJB-7 > URL: http://jira.codehaus.org/browse/MEJB-7 > Project: Maven 2.x Ejb Plugin > Type: Bug > Reporter: Todd Nine > > > The transitive classpath of all dependencies from the dependencies in an EJB > pom are not added to the MANIFEST.MF classpath. This causes the ejb to not > deploy correctly. > Todd -- 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
[jira] Commented: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ http://jira.codehaus.org/browse/MWAR-9?page=comments#action_61986 ] Mark Chesney commented on MWAR-9: - I have a patch which is attached to MWAR-21 which supports a minimal type WAR packaging within an EAR. See http://jira.codehaus.org/browse/MWAR-21 . It does not support a combination of EAR and WEB-INF/lib dependencies, just one or the other. > 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 > Type: Improvement > Reporter: Mike Perham > > > 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
[jira] Updated: (MWAR-21) Need a way to include limited set of webapp's dependencies
[ http://jira.codehaus.org/browse/MWAR-21?page=all ] Mark Chesney updated MWAR-21: - Attachment: MWAR-21-workaround.patch > Need a way to include limited set of webapp's dependencies > -- > > Key: MWAR-21 > URL: http://jira.codehaus.org/browse/MWAR-21 > Project: Maven 2.x War Plugin > Type: Improvement > Environment: M2.0.1 > Reporter: Dirk Olmes > Assignee: John Tolentino > Priority: Blocker > Fix For: 2.0 > Attachments: AbstractWarMojo.diff, MWAR-21-workaround.patch > > Time Spent: 6 hours >Remaining: 0 minutes > > I need a way to pack a war that includes only a limited set of the webapp's > dependencies. We're deploying in mainly two different environments: for > testing, the webapp runs standalone and thus needs to include all its > dependencies in the war. For production we deploy the webapp into a JBoss > server that has all the dependencies already installed. > I've modified AbstractWarMojo in the following way: 1) allow to specify > dependencyIncludes an dependencyExcludes (as lists) 2) upon building the war, > each dependency is checked against the excludes and the includes and will be > added to the war accordingly. > While this patch may not be the best way to to it, it clearly shows my > requirements. -- 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
[jira] Commented: (MWAR-21) Need a way to include limited set of webapp's dependencies
[ http://jira.codehaus.org/browse/MWAR-21?page=comments#action_61972 ] Mark Chesney commented on MWAR-21: -- You're missing an important aspect of J2EE packaging. If a dependency is included in the EAR to be used by J2EE modules within the same EAR, it must be listed in the manifest of that module. To have these dependencies included in the manfiest of the WAR using existing mechanisms, the WAR plugin must be configured like like so: maven-war-plugin true Provided scope dependencies will not be included in the WAR manifest. Compile and Runtime scope dependencies will be added to the WAR manifest. The WAR plugin also packages compile and runtime scope libraries in WEB-INF/lib. Not only is this redundant, but it can cause Class Cast Exceptions. The J2EE spec allows for any combination of WAR dependencies packaged in the EAR or within WEB-INF/lib, not just one or the other. Please see the J2EE 1.4 specification (http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf) section 8.2, for valid J2EE packaging use cases. > Need a way to include limited set of webapp's dependencies > -- > > Key: MWAR-21 > URL: http://jira.codehaus.org/browse/MWAR-21 > Project: Maven 2.x War Plugin > Type: Improvement > Environment: M2.0.1 > Reporter: Dirk Olmes > Assignee: John Tolentino > Priority: Blocker > Fix For: 2.0 > Attachments: AbstractWarMojo.diff > > Time Spent: 6 hours >Remaining: 0 minutes > > I need a way to pack a war that includes only a limited set of the webapp's > dependencies. We're deploying in mainly two different environments: for > testing, the webapp runs standalone and thus needs to include all its > dependencies in the war. For production we deploy the webapp into a JBoss > server that has all the dependencies already installed. > I've modified AbstractWarMojo in the following way: 1) allow to specify > dependencyIncludes an dependencyExcludes (as lists) 2) upon building the war, > each dependency is checked against the excludes and the includes and will be > added to the war accordingly. > While this patch may not be the best way to to it, it clearly shows my > requirements. -- 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
