Maven Integration for Eclipse WTP 0.15.0, a.k.a m2eclipse-wtp, a.k.a m2e-wtp is available.
This release contains mostly bug fixes, but a few improvements managed to slip in. The complete release notes are available here.
Update 08/02/2012 : m2e-wtp 0.15.1 has been released to fix a build related issue, but is strictly identical to 0.15.0 in terms of code/features
m2e-wtp 0.15.0 is compatible with the JavaEE distributions of Eclipse Helios and Indigo, requires at least m2e 1.0 (works with 1.1) and mavenarchiver plugin >= 0.14.0 (0.15.0 should be automatically installed).
As usual, m2e-wtp can be installed from :
- the Maven Discovery mechanism, for new installations : Window > Preferences > Maven > Discovery > Open catalog
- the Eclipse Marketplace : Help > Eclipse Marketplace
- the update site : http://download.jboss.org/jbosstools/updates/m2eclipse-wtp/
So let's see what are the highlights of this new release :
Packaging inclusion/exclusion support improvements
For war project, previous m2e-wtp versions used to use <packagingIncludes> and <packagingExcludes> attributes from the maven-war-plugin config to enable (or not) the deployment of project dependencies to WTP servers. In 0.15.0, the same level of support has been added to EAR projects using maven-ear-plugin 2.7+. However, the problem with this approach is, other resources (web pages, classes ...) are not properly excluded (using the <*SourceInclude> and <*SourceExclude> attributes).
In order to address this problem, Rob Stryker, committer on WTP and lead of JBoss AS tooling in JBoss Tools, provided an implementation for JBoss AS servers that might be generalized to other WTP server adapters (if they decide to do so). Basically, some new metadata is added to the project's .settings/org.eclipse.wst.common.component like :
<?xml version="1.0" encoding="UTF-8"?> <project-modules id="moduleCoreId" project-version="1.5.0"> <wb-module deploy-name="webOrEar"> ... <property name="component.inclusion.patterns" value="pattern1,pattern2"/> <property name="component.exclusion.patterns" value="pattern3,pattern4"/> </wb-module> </project-modules>
The patterns are separated with a comma and exclusions take precedence over inclusions : resources matching one of the exclusion patterns are not deployed, even if they match one of the inclusion patterns. That solution is not maven-bound so any other kind of project can benefit from it.
Now all m2e-wtp 0.15.0 does is map the maven patterns to their equivalent component metadata. This gives :
In the example above, a warning is displayed as both <warSourceIncludes> and <packagingIncludes> are defined. Since both patterns could overlap, it might lead to some weird behavior where WTP would actually deploy more files than a maven CLI build. In order to minimize (we can not totally solve) that potential discrepancy we only keep the packaging patterns in the component files and recommend using <packagingIncludes> only.
Currently, this feature only works in combination with the JBoss AS Tools from JBoss Tools 3.3.0.Beta1 (nightly builds available from http://download.jboss.org/jbosstools/updates/nightly/trunk/), but we'll try to make other WTP Server adapter vendors support it in the future (as part of WTP core API).
Warnings added when unsupported dependency types are detected
As of today, if a project depends on another workspace project of type ejb-client or test-jar, that specific dependency will not be packaged properly by WTP, as Maven would do in command line. Moreover, you'll experience some class leakage on the compilation and test classpaths in Eclipse (ex: non client classes being visible). The only known workarounds to this issue are to disable workspace resolution, or close the dependent project and rely on the dependencies from the local maven repository.
Ideally, in order to make the deployment part work, we would need to introduce new WTP components, but the current WTP API doesn't support it, yet. So, until this is fixed, warning markers are added whenever a project depends on such "unsupported" types. That should hopefully give users an idea of the problem and how to circumvent it.
Better handling of dependencies in war projects
Previous m2e-wtp versions had, in some use cases, some outstanding issues with regard to dependency management of war projects. In particular,
- when 2 dependencies of the same artifact, but having a different classifier were added to a web project, only one would show up on the classpath. This has been properly fixed.
- in some cases, the timestamped version of a SNAPSHOT dependencies from the local repository, would be copied under the target/ folder, causing some jar locking issues in windows. The rationale behind this behavior is, maven-war-plugin packages snapshot dependencies using the timestamp identifier. Since the name of file in the maven classpath library needs to match the one deployed by WTP, a copy was performed. To fix this problem, the default file pattern matching used for dependency deployment has been changed to @{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@. This means that, by default in m2e-wtp, SNAPSHOT dependencies are now deployed using the SNAPSHOT suffix instead of the timestamp. If you need to force the use of timestamped artifacts, then you need to explicitely decalre the following in your pom.xml :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<outputFileNameMapping>@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@</outputFileNameMapping>
</configuration>
</plugin>
Removal of conflicting facets on packaging change
If you had a java utility project, that you wanted to upgrade to an EJB project for example, a constraint violation would be raised upon project configuration update (EJB and Utility facets can't be both installed).
This has been fixed by removing all conflicting facets when you change the packaging of a Java EE project, making that conversion completely transparent.
What's next?
m2e 1.1 introduces a new Eclipse to Maven project conversion API. It means that, in m2e-wtp.next, we will be able to automatically convert existing WTP project configuration to maven's. Dependencies will still need to be set/translated manually but that's a pretty good start IMHO.
Finally ...
I would like to thank the m2e-wtp community at large for their support and contributions, that's what make this project move forward and make it one of the most popular projects on the eclipse marketplace.
Contributions can take the form of :
- patches/pull requests (source is available on https://github.com/sonatype/m2eclipse-wtp/), as Laszlo Varadi did to fix some overlay issue in windows,
- bug reports (at https://issues.sonatype.org/browse/MECLIPSEWTP)
- help on the documentation in the wiki.
- answering questions on the m2e mailing list
Keep it up.
Fred.