Re: [m2e-users] New m2e-wtp behaviour regarding classpath management

[Fred Bricon <fbricon@xxxxxxxxx>]

Chuck, 

the <manifestFile> option is supported, so you can really use custom stuff (see the test case : https://github.com/sonatype/m2eclipse-wtp/blob/master/org.maven.ide.eclipse.wtp.tests/src/org/maven/ide/eclipse/wtp/ManifestConfiguratorTest.java#L178 and https://github.com/sonatype/m2eclipse-wtp/blob/master/org.maven.ide.eclipse.wtp.tests/projects/manifests/ejb-provided-manifest/src/main/resources/META-INF/MANIFEST.MF)

2011/6/16 Chuck Bridgham <cbridgha@xxxxxxxxxx>

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 <fbricon@xxxxxxxxx>
To:        Maven Integration for Eclipse users mailing list <m2e-users@xxxxxxxxxxx>
Cc:        Chuck Bridgham/Raleigh/IBM@IBMUS, Max Rydahl Andersen <max.andersen@xxxxxxxxxx>, Snjezana Peco <snjezana.peco@xxxxxxxxxx>
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 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

-- 
"Have you tried turning it off and on again" - The IT Crowd