Chuck,
with regards to your annotation scanning policy, you don't need an extra
MANIFEST, just an extra manifest entry in the manifest configuration :
<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>
<Ignore-Scanning-Packages>org.apache.avalon,
org.apache.batik, org.apache.commons</Ignore-Scanning-Packages>
</manifestEntries>
</archive>
</configuration>
</plugin>
renders :
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
Ignore-Scanning-Packages: org.apache.avalon, org.apache.batik, org.apa
che.commons
2011/6/16 Chuck Bridgham <[email protected]>
> Yep, completely agree - just wanted to mention existing api.. But per
> project datamodel properties are needed - please open an enhancement -
>
> Max - An example of a server specific MANIFEST entry could be for an
> annotation scanning policy ->
>
> Ignore-Scanning-Packages : org.apache.avalon, org.apache.batik,
> org.apache.commons
>
> Thanks - Chuck
>
> RAD Architect, Java EE Tools, WTP PMC
> IBM Software Lab - Research Triangle Park, NC
>
>
>
> From: Fred Bricon <[email protected]>
> To: Chuck Bridgham/Raleigh/IBM@IBMUS
> Cc: Maven Integration for Eclipse users mailing list <
> [email protected]>, Max Rydahl Andersen <[email protected]>,
> Snjezana Peco <[email protected]>
> Date: 06/16/2011 10:04 AM
> Subject: Re: New m2e-wtp behaviour regarding classpath management
> ------------------------------
>
>
>
> 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]* <[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]* <[email protected]>>
> To: Maven Integration for Eclipse users mailing list <*
> [email protected]* <[email protected]>>
> Cc: Chuck Bridgham/Raleigh/IBM@IBMUS, Max Rydahl Andersen <*
> [email protected]* <[email protected]>>, Snjezana Peco <*
> [email protected]* <[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
>
--
"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
