About the workspace preference settings, I'm not sure m2e-wtp should touch these. That could potentially break non maven project behaviour. If I were to use them now, I would have to : - store existing UseXYZLibrary value in a local variable, - set UseXYZLibrary to false - add facet - restore UseXYZLibrary to its former value
I would prefer some options passed to the IDataModel like IDataModel modelConfig = .... modelConfig.setProperty(USE_WEBAPP_LIBRARY, false); modelConfig.setProperty(GENERATE_MANIFEST, false); If that sounds reasonable, I'll create the feature requests on BZ. regards, Fred Bricon 2011/6/16 Chuck Bridgham <[email protected]> > Thanks Fred, > > These are very useful features.. > > In testing m2e-wtp - I also remove the WTP containers as they duplicate the > Maven container's purpose. For new projects, there is an existing > preference setting in WTP that disables these libraries from being added > (Doesn't remove entries from existing projects).. They are > J2EEPreferences.getUseEARLibraries() and *J2EEPreferences*. > getUseWebLibaries() - misspellings and all! - Of course these are > workspace preferences, but it may be worth settings these to false or > exposing these as part of m2e -wtp preferences? > > I'm also worried about the MANIFEST generation. I agree wtp should be more > flexible for source folder MANIFEST file generation, but in our case we need > a source copy. I know there used to be a pom setting to re-use an existing > MANIFEST file in the generation of the archive copy. This is important to > us, because of server specific settings that are specified in the MANIFEST > file. > > We recommended using something like this: > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-jar-plugin</artifactId> > <configuration> > <archive> > > <manifestFile>src/main/java/META-INF/MANIFEST.MF</manifestFile> > </archive> > </configuration> > > Do you know if we can still re-use a file AND generate the "Class-Path: " > section based on the pom? > > Thanks - Chuck > > RAD Architect, Java EE Tools, WTP PMC > IBM Software Lab - Research Triangle Park, NC > > > > From: Fred Bricon <[email protected]> > To: Maven Integration for Eclipse users mailing list < > [email protected]> > Cc: Chuck Bridgham/Raleigh/IBM@IBMUS, Max Rydahl Andersen < > [email protected]>, Snjezana Peco <[email protected]> > Date: 06/16/2011 04:39 AM > Subject: 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*<https://issues.sonatype.org/browse/MECLIPSEWTP-133>Remove > Webapp and EAR classpath libraries from WTP projects > [2] > *https://issues.sonatype.org/browse/MECLIPSEWTP-10*<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*<https://issues.sonatype.org/browse/MECLIPSEWTP-52>Optional > dependencies are available during dependent web projects tests > [4] > *https://issues.sonatype.org/browse/MECLIPSEWTP-91*<https://issues.sonatype.org/browse/MECLIPSEWTP-91>WTP > and Multi-module project woes > [5] > *https://issues.sonatype.org/browse/MECLIPSEWTP-45*<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/ > *<http://download.jboss.org/jbosstools/builds/staging/m2eclipse-wtp-e37/all/repo/> > > -- > "Have you tried turning it off and on again" - The IT Crowd > -- "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
