Paul, please open an enhancement request. I'll see if I can slip it in m2e-wtp 0.13.0, since it sounds trivial to do. But don't have too much hope.
regards, Fred Bricon 2011/6/21 Paul Vonnahme <[email protected]> > Fred, > > First let me say I appreciate all the work you've done on this plugin. > > In reference to your latest changes, would it be possible to add an > option in the workspace preferences as to the location of the > generated manifest for wars? Maybe have it default to > target/m2e-wtp/web-resources/, but have a spot we can uncheck if we > want it generated in the source directory? This would be consistent > with the existing Workspace->Preferences->Maven->WTP Integration->"EAR > Project preferences"->"Generate application.xml under the build > directory" option, and it would be very much appreciated. > > It's been quite a while since I've looked at the code, but if a patch > would help, I'd be willing to give it a shot. > > Thanks, > Paul > > > From: [email protected] [mailto: > [email protected]] > > On Behalf Of Fred Bricon > > Sent: Thursday, June 16, 2011 3:38 AM > > To: Maven Integration for Eclipse users mailing list > > Cc: Max Rydahl Andersen; Chuck Bridgham > > Subject: [m2e-users] New m2e-wtp behaviour regarding classpath management > > > > Hi, > > > > 2 significant changes have been made to m2e-wtp 0.13.0 with regard to > > classpath management : > > > > - The WTP classpath libraries are gone [1] : The webapp and EAR libraries > > always conflicted somehow with the Maven library. In order to workaround > > these conflicts, we basically had to jump through hoops to move > classpath > > entries from one library to the other. Another big problem we had while > > keeping the WTP libraries was dependency leakage when running unit tests > > [2][3][4]. The Maven library handles test dependencies very well, but > once > > you add the WTP libraries, you start seeing inconsistent behavior between > > Maven CLI and Eclipse. This is because regular WTP dependencies basically > > add EVERYHTING to the classpath. > > > > - Manifest management has been changed [5]. Before, in m2e-wtp, the > manifest > > was generated "manually" using WTP's API, for web projects only. In the > > process, the manifest kinda fixed some maven shortcomings in order to > handle > > skinny wars (didn't add a classpath prefix for EJBs, contrary to maven). > > Now, for Web, EAR, EJB, Utility and Connector projects, a manifest is > > generated via a call to the Maven's archiver. > > That means no more impedance mismatch between Maven and Eclipse > manifests. > > Manifest customization is reflected on the fly in the generated file. > > For jar, ejb and connector projects, it is generated under > target/classes. > > For web projects, it goes under target/m2e-wtp/web-resources/ and for > EARs, > > goes under target/m2e-wtp/ear-resources/ > > Since the EAR library is gone, the manifest is no longer used to reflect > > compile classpath within Eclipse and is only used for runtime classpath > > resolution. > > Since it now follows the same rules as Maven, how do you handle skinny > wars > > with ejbs and classpath prefix? One solution is to use your own > Class-Path > > entry, which will be appended with the classpath computed by the maven > > archiver. So, for instance : > > > > <plugin> > > <groupId>org.apache.maven.plugins</groupId> > > <artifactId>maven-war-plugin</artifactId> > > <version>2.1.1</version> > > <configuration> > > > <warSourceExcludes>WEB-INF/lib/*.jar</warSourceExcludes> > > <archive> > > <manifest> > > <addClasspath>true</addClasspath> > > <classpathPrefix>lib/</classpathPrefix> > > </manifest> > > <manifestEntries> > > > > <Class-Path>sample-ejb-${pom.version}.jar</Class-Path> > > </manifestEntries> > > </archive> > > </configuration> > > </plugin> > > > > will generate something like : > > > > Manifest-Version: 1.0 > > Built-By: fbricon > > Build-Jdk: 1.6.0_24 > > Class-Path: sample-ejb-0.0.1-SNAPSHOT.jar lib/sample-util-0.0.1-SNAPSH > > OT.jar > > Created-By: Maven Integration for Eclipse > > > > Of course, the "Created-By: Maven Integration for Eclipse" entry can be > > overwritten using your own value : > > <manifestEntries> > > <Created-By>My kick-ass IDE</Created-By> > > </manifestEntries> > > > > One last thing, I've tried to delete all new MANIFESTS.MFs automatically > > generated by WTP. So hopefully, your source control shouldn't be polluted > > anymore. > > > > You can try the nightly build to test these changes, see if it doesn't > > disrupt existing behaviour in your projects [7] > > m2e-wtp 0.13.0 works with m2e 1.0.0 and is compatible with Helios (e3.6) > and > > Indigo (e3.7). It's incompatible with former Eclipse versions > > > > Expect a new release next week, at the same time as Eclipse Indigo -more > or > > less-. > > > > regards, > > > > Fred Bricon > > > > [1] https://issues.sonatype.org/browse/MECLIPSEWTP-133 Remove Webapp and > EAR > > classpath libraries from WTP projects > > [2] https://issues.sonatype.org/browse/MECLIPSEWTP-10 Wrong runtime > > classpath resolution for war packaging: application-classpath includes > test > > classes from dependencies (projects) > > [3] https://issues.sonatype.org/browse/MECLIPSEWTP-52 Optional > dependencies > > are available during dependent web projects tests > > [4] https://issues.sonatype.org/browse/MECLIPSEWTP-91 WTP and > Multi-module > > project woes > > [5] https://issues.sonatype.org/browse/MECLIPSEWTP-45 Bad MANIFEST in > Jar > > (WTP) > > [6] > > > http://download.jboss.org/jbosstools/builds/staging/m2eclipse-wtp-e37/all/repo/ > > > > -- > > "Have you tried turning it off and on again" - The IT Crowd > _______________________________________________ > m2e-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/m2e-users > -- "Have you tried turning it off and on again" - The IT Crowd
_______________________________________________ m2e-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/m2e-users
