On behalf of the JBoss Tools and Developer Studio team, I am extremely proud to announce the general availability of the JBoss Tools 4.1.2.Final and Red Hat JBoss Developer Studio 7.1.1.GA releases.
JBoss Tools 4.1.2.Final and Developer Studio 7.1.1.GA
JBoss Tools is a set of plugins for Eclipse that complements, enhances and goes beyond the support that exists for JBoss and related technologies in the default Eclipse distribution.
Red Hat JBoss Developer Studio is a fully bundled Eclipse distribution which not only includes the majority of JBoss Tools but also all its needed dependencies and 3rd party plugins allowing for an easy one-click and no-fuss installation.
If you are into doing your own bleeding edge Eclipse plugin assembly, JBoss Tools is for you; if you are more into having something that "Just Works" then JBoss Developer Studio is the way to go.
Installation
If you already have JBoss Tools 4.1.1 or Developer Studio 7.1 installed using 'Help > Update' will give you this release automatically.
If you want a new installation, then JBoss Developer Studio is available as a one-download-installer with everything bundled and configured out of the box.
You can also install JBoss Developer Studio or JBoss Tools from Eclipse Marketplace via "Help > Eclipse Marketplace..."
When installing from Eclipse Marketplace we recommend using a fresh Eclipse 4.3.2 JEE Bundle since then you'll have most of the dependencies pre-installed.
Last one before Luna
JBoss Tools 4.1.2 and JBDS 7.1.1 are primarily focused on building on top of the latest Eclipse Kepler SR2 release, fixing 30 issues along. We keep on trying to make the life of Angular JS users easier, as you can see below.
This is the last planned release of the JBoss Tools 4.1.x and JBDS 7.1.x streams, based on Eclipse 4.3.x. Cool kids already play with the next milestones for Luna.
No mo' warnings
We backported one of the features we contributed to Eclipse Luna (Milestone 6), that is the ability to ignore non-standard HTML attributes. This is typically needed when developing Angular JS applications as the HTML validator considers Angular JS ng-* attributes as invalid html (which is actually correct since the proper syntax to be 100% compatible with the html5 spec is to use data-ng-*).
You can now quick-fix these warning (Ctrl+1) and choose to ignore specific or all similar attributes :
And if you're really into Angular JS, we recommend you try the AngularJS Eclipse plugin. We're currently evaluating it ourselves for inclusion in the next major version of JBoss Tools and Developer Studio.
Giving Feedback
Please don't hesitate to use our forum to ask questions, or, if you have ideas to better improve JBoss Tools / Developer Studio, or found a bug, then open an issue in our issue tracker.
What's Next ?
We're currently hard at work preparing the next iteration of JBoss Tools (4.2) and Developer Studio (8.0), targeted at Eclipse Luna. Brace yourself for the upcoming Beta releases in the next 2 to 3 weeks, with more awesome/cool/hip stuff ;-)
On behalf of the JBoss Tools and Developer Studio team, We are extremely proud to announce the general availability of the JBoss Tools 4.1.1.Final and Red Hat JBoss Developer Studio 7.1.0.GA releases.
JBoss Tools 4.1.1.Final and Developer Studio 7.1.0.GA
JBoss Tools is a set of plugins for Eclipse that complements, enhances and goes beyond the support that exists for JBoss and related technologies in the default Eclipse distribution.
Red Hat JBoss Developer Studio is a fully bundled Eclipse distribution which not only includes the majority of JBoss Tools but also all its needed dependencies and 3rd party plugins allowing for an easy one-click and no-fuss installation.
If you are into doing your own bleeding edge Eclipse plugin assembly, JBoss Tools is for you; if you are more into having something that "Just Works" then JBoss Developer Studio is the way to go.
Installation
If you already have JBoss Tools 4.1 or Developer Studio 7.0 installed using 'Help > Update' will give you this release automatically.
If you want a new installation then, JBoss Developer Studio is available with a one-download-installer with everything bundled and configured out of the box.
You can also install JBoss Developer Studio or JBoss Tools from Eclipse Marketplace via "Help > Eclipse Marketplace..."
When installing from Eclipse Marketplace we recommend using a fresh Eclipse 4.3.1 JEE Bundle since then you'll have most of the dependencies pre-installed.
More of the same, only better
JBoss Tools 4.1.1 and JBDS 7.1 are built on top of Eclipse Kepler SR1 (4.3.1) and are primarily focused on improving stability (more than 500 issues were fixed). Don't worry, we also added a bunch of new cool features, so make sure to read the complete New and Noteworthy for a detailed and complete overview.
We're still riding the Mobile first theme of our previous release, so let's take a look at some of the new feats :
Resource content assist and file creation
There are now content assist on resources for things like script, img, source, anchors etc.
Alexey made a nice video of how it works you can watch here.
Furthermore if you type in a resource that does not exist the html editing tools now offer to create the resource for you, making it much easier to quickly create a set of linked resources.
Angular.js attribute content assist
To aid in developing of Angular JS applications we've added content assist for ng-* attributes.
We are working on providing better angular support (i.e. content assist for actual values) but that requires more than we can safely include into a bugfix release
Another recurrent complaint is that the HTML validation considers Angular JS ng-* attributes as invalid html. This is actually correct since the proper syntax to be 100% compatible with the html5 spec is to use data-ng-* and if you disabled this rule you would loose warnings against you misspelling i.e. class as clas. This issue we can't fix in JBoss Tools alone thus we have submitted patches upstream to eclipse to allow you to choose to ignore ng-* and any other combination of attributes in your specific project. You can follow that here if you are interested.
Improved Hybrid Mobile (Cordova) tooling
The Hybrid Mobile tooling now supports Cordova 3. Gorkem put together a nice video of the Apache Cordova support provided by our Aerogear Hybrid tooling, demonstrating :
Project wizard
Native Device and Cordova simulators
Cordova plugins discovery and installation
Project export to native platforms
More OpenShift 2.0
Recent updates to OpenShift online and OpenShift Enterprise introduced the notion of user accounts having access to multiple domains. This is very useful if you are working together in a team and want to share access to your various applications.
The OpenShift tooling now fully supports multiple domains in the UI. These domains will show up in application creation and editing wizards and as shown below in the OpenShift Explorer.
other improvements include :
support for Environment Variables management
tailing logs of scaled applications
Giving Feedback
Please don't hesitate to use our forum to ask questions, or, if you have ideas to better improve JBoss Tools / Developer Studio, or found a bug, then open an issue in our issue tracker.
What's Next ?
Once we recover from all the end-of-year festivities, we'll resume our work on the next generation of JBoss Tools and Developer Studio, for Eclipse Luna.
On behalf of the JBoss Tools and Developer Studio team, I'm extremely proud to announce the general availability of the JBoss Tools 4.1.0.Final and Red Hat JBoss Developer Studio 7.0.0.GA releases.
JBoss Tools 4.1.0.Final and Developer Studio 7.0.0.GA
JBoss Tools is a set of plugins for Eclipse that complements, enhances and goes beyond the support that exists for JBoss and related technologies in the default Eclipse distribution.
Red Hat JBoss Developer Studio is a fully bundled Eclipse distribution which not only includes the majority of JBoss Tools but also all its needed dependencies and 3rd party plugins allowing for an easy one-click and no-fuss installation.
If you are into doing your own bleeding edge Eclipse plugin assembly, JBoss Tools is for you; if you are more into having something that "Just Works" then JBoss Developer Studio is the way to go.
Installation
JBoss Developer Studio is available with a one-download-installer with everything bundled and configured out of the box.
You can also install JBoss Developer Studio or JBoss Tools from Eclipse Marketplace via "Help > Eclipse Marketplace..."
When installing from Eclipse Marketplace we recommend using a fresh Eclipse 4.3 JEE Bundle since then you'll have most of the dependencies pre-installed.
Note: SOA tooling for BPEL, Drools, Guvnor, jBPM, ESB, Modeshape, pi4soa, Savara, SwitchYard & Teiid, in future referred collectively as the JBoss Tools or JBoss Developer Studio Integration Stack (JBT-IS or JBDS-IS), are not yet available for this release. They will become available separately later. If you wish to use these today we recommend you continue to use JBoss Tools 3.3 or JBoss Developer Studio 5.0, or try one installing the latest unsupported nightly build from this update site:
JBoss Tools 4.1.0 and JBDS 7.0 are built on top of Eclipse Kepler (e4.3), which brought noticeable performance and stability improvements over the previous Juno version (e4.2). But we also improved the performance in some of our own features (Central, JAX-RS tooling, Web Service testing).
We have so much good stuff this time around, it's hard to cram everything into a (readable) blog post, so I'll just present the major features we have here, introduced since JBoss Tools 4.0 and JBDS 6.0. But make sure to read the complete New and Noteworthy for a more detailed and complete overview.
TL;DR : The recurring theme of this release is "HTML5 and mobile development". Burr Sutter made a screencast highlighting several of the new features available in this release :
LiveReload
Probably the coolest new features we have, the new LiveReload server allows you to have your browser automatically refresh when you save your html, javascript and css files.You can just focus on content and functionality and instantly see and use the changes in your browser. If it is hard to imagine how it works, Xavier Coulon made a video showing how to activate and use it (on the right).
You should install a LiveReload plugin/extension into your browser as documented in our What’s New and Noteworthy. If you can't, don't worry, keep reading.
LiveReload supports local (i.e. file:// based urls) or content served out from an application server. In the latter case, the browser will reload once the files are published on the application server, especially useful when editing JSF content like xhtml.
You can right-click on files in the Project Explorer view or on modules deployed to a server, to load your Browser with a LiveReload enabled page. This action will setup the LiveReload server for you if it does not already exist :
Our server implements the existing defacto protocol used by the original LiveReload and related plug-ins, meaning any browser, script and tool that works with live reload today should work with our Eclipse implementation of it.
It's really nice to have instant feedback for HTML5/JS based applications. But wait, it's getting even better.
Proxying and Open in external Device
If your browser does not have the LiveReload plugin, like Safari or you're using a mobile device, you would normally manually add a livereload.js loading snippet in every web page. That can be tedious and requires changes to files you might not want to commit to your source repository. It's alright. Please meet our "LiveReload Proxying" :
It is enabled by checking "Inject the livereload.js script in HTML pages" in the LiveReload Server configuration. This allows you to proxy your file:// urls and have them served out on localhost:35729/<projectname>/<filepath> (or any other port if you choose so in the LiveReload Server configuration) .
For security reasons, remote connections are disabled by default, so if you want mobile devices to be able to load the page, just enable "Allow Remote Connections".
Now, typing a complex, long url on a mobile device can be tedious, so in order to make your life even easier, we've added a "Show In > Web Browser on External device..." menu. This will display a QR code for the LiveReload enabled url. Simply use a QR reader application and have the webpage load on your device. Watch your pages reload as you make the modifications in your IDE, it's close to black magic!
HTML5/JQuery Mobile Palette
To further improve your HTML5 / mobile development experience, we’ve added a new HTML5 palette with initial support for JQuery Mobile widgets. This palette will show up when you edit HTML5 files (files with <!DOCTYPE HTML> doc type). If it does not show up, it is probably using HTML4 or XHTML content types.
The JQuery Mobile palette features a dialog preview when you click or drag one of the buttons for a component, it lets you see and customize what will be inserted :
BrowserSim is a mobile web browser simulator, used to test your web pages on mobile devices with a realistic mobile device skin.
Now guess what? your mobile application development experience just scored 11. In this release, we've added a bunch of really exciting features, available with a right-click on the device bezel :
synched browsing : open the same web page in 2 different but synchronized browsers. You can test horizontal and landscape modes at the same time or view how layout behaves on different devices simultaneously.
screenshot : easily take screenshots to share your awesome design or nasty bug you want someone to hunt down.
debugging facilities : use Firebug Lite for easy local debugging, or debug remotely using any Weinre compatible server to debug/inspect the application running in BrowserSim.
new skins galore
Please note BrowserSim must be launched with a 32bits JRE (you can now select it in JBossTools > BrowserSim / Cordova preferences) and Safari must be installed on your machine.
Windows 64-bit Visual Page Editor
A long standing issue for our Visual Page Editor was the lack of proper Windows 64-bit XULRunner integration.
If real, cross-platform Mobile application development is your thing, we now have experimental support for developing Hybrid mobile applications with Apache Cordova.
You can create an "Hybrid Mobile" project and test and develop it using the Android SDK and XCode for iOS testing.
Note: this is only available as Experimental in JBoss Tools, not part of Developer Studio (yet)
CordovaSim (Experimental)
To help testing hybrid mobile development we've extended our BrowerSim to use Ripple to provide a way to do portable testing (meaning you do not necessarily need Android or XCode installed to do development)
Note: this is only available as Experimental in JBoss Tools, not part of Developer Studio (yet)
Forge integration
The majority of the feedback we got for the awesome integration of Forge into Eclipse was that many preferred to use a wizard over only having access to a "command line style" UI.
We listened to you and added new wizards, to give an Eclipse front-end to the following Forge features:
Generate Entities from existing tables
Generate REST Endpoint from Entities
Scaffold UI (JSF or AngularJS based) from Entities
You will find these wizards - which are Technology Preview as of this release - under "File > New > JBoss Tools":
Make sure you read a detailed description of these wizard in Forge What's New. Oh and to make it all work, we now embed the Forge 1.3.3.Final runtime.
Please note these wizards are considered Technology Preview, thus, even though they're included, are not supported in JBoss Developer Studio.
The long term goal is to get a closer integration between Forge and Eclipse. This is a current work in progress with Forge 2, which is now available as an experimental download for JBoss Tools
Arquillian (Experimental)
Arquillian Eclipse is a new JBoss Tools component that makes Java EE integration testing using Arquillian easier. The Arquillian support can be added/removed by right-clicking the project and selecting Configure>Add/Remove Arquillian support.
The project has to be a Maven (m2e) project. The "Add Arquillian Support" action adds the Arquillian nature to the project as well as arquillian artifacts (bom, dependencies, required plugins, profiles ...) to the project's pom.xml. The Remove Arquillian Support removes the Arquillian nature, but doesn't change the project's pom.xml.
A new "Arquillian JUnit Test Case" wizard, based on the JUnit Test Case wizard, adds the following to a created class:
@RunWith(Arquillian.class) annotation
the deployment method
Enabling Arquillian support also brings you validation, navigation across arquillian resources, launch configuration... You'll most certainly want to read a more complete overview of the Arquillian support here.
Note: this is only available as Experimental in JBoss Tools, not part of Developer Studio (yet)
OpenShift
OpenShift Tools received a good deal of improvements, usability wise. Improved UI, more explicit labels where needed, but more importantly :
Git output streaming
Ever since we added OpenShift support to Eclipse we've had the problem that EGit did not allow streaming of console output when performing a push.
This mean that when doing a long running push Eclipse would just have a blank console and show "Push in progress".
In Kepler, EGit now includes our contribution of allowing this meaning Git users and OpenShift users can and will get streaming of the console output. You can now see what is going on.
Restart OpenShift Application
We've added "Restart" to the UI, allowing you to trigger a node restart for your application in case something bad has happened or you changed a configuration that requires a full node restart.
Create application from a remote repository
Opening the advanced section of the New OpenShift Appliction wizard, you can now create an application directly seeded from a remote git repository (github for instance) instead of forcing you to use git recursive merges locally.
Configure OpenShift markers
OpenShift is using markers to enable or disable features. These markers are hidden files added to the <project>/.openshift/markers directory. You can now add/remove/edit these markers by invoking a wizard from the OpenShift > Configure Markers... menu in th Project- or Package-Explorer.
Application creation logs
When creating applications you want to know about the credentials that OpenShift initially set for you. This is especially helpful and required when you create a jenkins where you get its url and username/password presented. We now display what OpenShift did for you if there's anything to be noticed for any type of application and/or cartridge.
JBoss Central
JBoss Central, the welcome screen of JBDS / JBoss Tools has a new design. We've tried to make it easier for you to get started building new applications, providing more samples, displaying descriptions of what each wizard gives you.
You can also access wizards for features you haven't installed yet, such as the OpenShift Application. You'll be prompted to install the required OpenShift Tools feature if you haven't installed it already.
In the software/update tab, you'll find we have added VJet, a promising new JavaScript editor, which should help you build, you know, HTML5 and mobile applications.
Servers and runtimes
New server adapters
JBoss EAP 6.1, freely available to developers (you can get it from the JBoss AS download page), now has its own server adapter.
WildFly now also has its own dedicated server adapter. Please note it's still considered experimental as WildFly itself is not stabilized to this day. We recommend using the latest Alpha-3 release, which fixes some file locking issue on windows and now support JSP development mode.
Better server identification
Servers derived from JBoss AS 7.x (JPP, SOA-P, GateIn), are now properly identified, making searching runtimes easier to setup. We now reuse the stacks.yml descriptor provided by the JBoss Developer Framework to provide downloads of different runtimes and thus providing a consistent experience, as part of the JBoss Way initiative.
Better server management
Server tools now uses the AS 7.x/EAP/WildFly management api, allowing for faster and more reliable (re)starts of servers, as well as better module management (individual module restart, status information).
Tomcat runtime detection (JBoss Tools only)
A new Tomcat runtime feature detection allows you to automatically detect and create tomcat-based servers, after scanning a specified server directory.
Maven Integration++
m2e 1.4.0 and m2e-wtp 1.0.0
JBDS comes with m2e 1.4.0 which brings some performance enhancements, as well as a very convenient Alt-F5 shortcut, to update project configuration, when it's gone out-of-synch.
we contributed the JBoss JPA/JSF/JAX-RS configurators to the m2e-wtp project at eclipse.org, which just graduated from the Eclipse Incubator into version 1.0.0, adding support to Java EE 7.
In this Kepler release the configuration of these configurators moved under the Preferences > Maven > Java EE Integration.
Automatic Source Lookup for the masses
Ever tasted m2e's awesome automatic source download but were frustrated when going back to work on legacy, non-maven projects? Then rejoice, we now enable automatic source lookup for *all*, non-maven java projects.
The automatic Source Lookup feature is based on Maven/m2e. As such, downloaded sources will be stored under your local Maven repository.
Since JDT doesn't support variables in source attachments (such as M2_REPO), source attachments use absolute (non-portable) paths. It's ok when the jar is part of a Classpath Library, since the path is stored in your own workspace. But it can become a problem if your jar dependency is listed in your project's .classpath descriptor, potentially shared with other developers. For this reason, by default, you'll be warned when a compatible source has been found :
The good news is the source lookup mechanism is capable of fixing bad source attachements, even for Maven enabled projects. If the attached source doesn't exist (ex. you wiped out your maven local repository or shared hard-coded source attachments in your scm) or doesn't contain the right source files, it will try to download the proper source.
Maven repository edition
Maven Repositories defined in profiles in your settings.xml (Window > Preferences > JBoss Tools > Maven Integration > Configure Maven Repositories...) can now be edited with the "Edit Repository..." button :
And much more...
there's not enough room here to list all the great things the team managed to pull. Better JAX-RS tooling performance, JSF 2.2 and updated Deltaspike support, improved web service tester (now using JBoss Wise). So, again, make sure you take a look at the news and screenshots in our What's New page.
Giving Feedback
Please don't hesitate to use our forum to ask questions, or, if you have ideas to better improve JBoss Tools / JBDS, or found a bug, then open an issue in our issue tracker.
What's Next ?
First, some of us are gonna take a tiny bit of rest in the coming weeks. Then we'll work on a service release, mainly focused on bug fixes, to accompany the Eclipse Kepler SR1 release in september. Hopefully, new features should see the light of day by the end of the year.
On behalf of the m2e-wtp team, I'm pleased to announce the immediate availability of m2e-wtp 0.17.0, right on time to accompany the Juno SR2 release.
This 0.17.0 release primarily introduces new optional Java EE configurators, contributed by the JBoss Tools and JBoss Developer Studio team.
JAX-RS project configurator : installs the JAX-RS Facet to war projects having JAX-RS dependencies
JSF project configurator : installs the JSF Facet to war projects having a WEB-INF/faces-config.xml, JSF dependencies or defining a FacesServlet in web.xml
JPA project configurator : installs the JPA Facet to java projects having a META-INF/persistence.xml descriptor
Read the New and Noteworthy and changelog to learn more about the new features and fixes this version brings to you.
Installation and gotchas
m2e-wtp requires at least m2e 1.1 but 1.3 is *strongly* recommended, in order to take advantage of the eclipse-to-maven project conversion improvements, as well as some fixes in classpath resolution for launch configurations.
Since WTP's Dali project changed its API between Juno and Kepler, so m2e-wtp is now available from 2 different update sites :
Please note that, m2e-wtp and JBoss Tools JPA, JSF JAX-RS Configurators overlap and can not be installed together.
In Eclipse versions prior to Juno SR2, if you try to update your Eclipse installation via "Help > Install New Software...", the optional configurators won't install because of the conflict with JBoss Tools. If you updated your version of Eclipse to Juno SR2, the m2e-wtp configurators should be seen as suitable replacement for their JBoss Tools counterparts.
For all Eclipse versions, if you add the m2e-wtp update site to your list of Available Update Sites, doing "Help > Find Updates" everything should update properly.
As always, the safest path to upgrade is to start from a clean Eclipse installation.
Destination Kepler
In the next version, we'll make sure Java EE 7 is given some proper love (i.e. make sure all the new upcoming Facet will be properly configured automatically).
And if everything goes according to plan, starting from Kepler Milestone 6, m2e-wtp.next should be included in the Eclipse Java EE distribution.
Last March, Max was blogging about moving the m2eclipse-wtp project to the Eclipse Foundation. We already had a website,
now I'm proud to announce the move is complete with the immediate availability of m2e-wtp 0.16.0, straight up from Eclipse.org's servers
and just in time to accompany the Juno SR1 release.
This 0.16.0 release, while being primarily focused on bug fixes from the former m2eclipse-wtp version, adds some new features to help you convert your Java EE Eclipse projects to Maven.
Please note that, m2e-wtp and Sonatype's m2eclipse-wtp overlap and can not be installed together.
if you try to update your Eclipse installation via "Help > Install New Software...", m2e-wtp won't install because of the conflict with m2eclipse-wtp (this is a bug in p2).
if you add the m2e-wtp update site to your list of Available Update Sites, doing "Help > Find Updates" should find m2e-wtp as a suitable replacement for m2eclipse-wtp, and everything should update properly.
The safest path to upgrade is to start from a clean Eclipse installation. Good thing you just downloaded Juno SR1 right?
Oh, by the way, JBoss Tools 4.0.0.Alpha2 and JBDS 6.0.0 Alpha2, coming in the next few days, will be compatible with m2e-wp 0.16.0.
Looking forward
The project is still incubating at the Eclipse Foundation, while we're working on stabilizing it, its API and working on new features. We're hoping to make m2e-wtp part of the Kepler release train,
and why not, integrate it direclty into the Eclipse Java EE distribution next June.
Finally I'd like to give some kudos to the WTP team from IBM, who was really instrumental with the project migration to eclipse.org and who also provided several patches to m2e-wtp.
I'm confident that, together, we'll be able to greatly improve both m2e-wtp and WTP itself.
Maven Integration for Eclipse JDT Annotation Processor Toolkit a.k.a m2e-apt is now available in its version 1.0. m2e-apt aims at providing automatic Annotation Processing configuration in Eclipse based on your project's pom.xml and its classpath dependencies (Requires Java >= 1.6).
The generated source folders (target/generated-sources/annotation for maven-compiler-plugin; target/generated-sources/apt for maven-processor-plugin) are automatically added to the project classpath.
By default, Annotation Processing is managed by Eclipse JDT APT, so a change in your source classes triggers incremental processing automatically. The downside of using JDT APT is, there's no separation between main and test classes (the way maven-processor-plugin handles them).
To mitigate that limitation, you can change the workspace or project preferences to delegate annotation processing to maven, instead of JDT APT. This will result in slower incremental builds (all classes will be processed) but will provide identical results to maven command line builds. Note this only works when using maven-processor-plugin. When annotation processing is driven by maven-compiler-plugin, JDT APT is always used in eclipse.
Automatic annotation processing configuration from the maven pom.xml can also be disabled altogether. In this case, your manual settings for Eclipse JDT APT will remain untouched.
Go to Window > Preferences > Maven > Annotation processing or right-click on your project > Properties > Maven > Annotation processing to select the Annotation Processing strategy of your choice.
m2e-apt is heavily based on the work from two community members :
a patch for m2e by Karl M. Davis, from Knowledge Computing Corp, implementing Eclipse JDT APT configuration based on the maven-compiler-plugin's configuration.
com.excilys.ebi.m2e.apt by Stéphane Landelle, from eBusiness Information, Excilys Group, implementing direct maven-processor-plugin invocation from m2e.
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 abuild 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
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 :
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 :
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.
While developping web applications, it's common best practice to minify (and sometimes obfuscate) static resources such as javascript and css files.
Such resource processing can be done either at build time or at run time, depending on the tools you're using.
Surprisingly, tooling and documentation is rather scarce when it comes to web resource optimization in the Eclipse World.
On the other hand, maven has a wide variety of plugins wrapping around well-known 3rd party optimizers. In particular, Web Resource Optimizer for Java, a.k.a WRO4J is a :
"Free and Open Source Java project which brings together almost all the modern web tools: JsHint, CssLint, JsMin,
Google Closure compressor, YUI Compressor, UglifyJs, Dojo Shrinksafe, Css Variables Support, JSON Compression,
Less, Sass, CoffeeScript and much more. In the same time, the aim is to keep it as simple as possible and as
extensible as possible in order to be easily adapted to application specific needs."
http://code.google.com/p/wro4j/
While WRO4J can be used at runtime, it also provides a maven plugin if you prefer a build time approach : wro4j-maven-plugin,.
Since Eclipse WTP allows you to incrementally deploy changed resources in your workspace directly to your prefered application server,
having a way to do on-the-fly resource optimization deployment would be great, wouldn't it?
Now, m2e (the Maven Integration for Eclipse plugin) users probably know, or will know soon enough, that m2e doesn't run maven plugins it doesn't know about. So having
would result in the dreaded "plugin execution not covered" error. Indeed, since Eclipse is all about incremental building (i.e. builds modified resources as soon as they're saved),
triggering long-running maven plugin every time a file is changed in the workspace would be a disaster. So m2e requires users to be explicit about what maven plugins should be run and when.
As a consequence, in order for these unknown plugins to be run on incremental builds, users need to modify their project pom.xml (or their parent pom.xml) and add a lifecycle-mapping configuration like (in the case of wro4j) :
<pluginManagement>
<plugins>
<!--This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself.-->
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>ro.isdc.wro4j</groupId>
<artifactId>wro4j-maven-plugin</artifactId>
<versionRange>[1.0,)</versionRange>
<goals>
<goal>run</goal>
</goals>
</pluginExecutionFilter>
<action>
<execute/>
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
...
</plugins>
Eventually, that lifecycle mapping would execute WRO4J on each and every file change in your project. That's a bit extreme, but the biggest problem is the generated files wouldn't be synchronized with the workspace so wouldn't be deployed automatically on a WTP server.
Here comes the m2e-wro4j connector : it's an eclipse plugin (in its early phase) that :
doesn't need the extra wro4j-maven-plugin lifecycle mapping
allows wro4j-maven-plugin to be invoked when .js, .css, .coffee, .less, .scss files are modified. Modifying the pom.xml also triggers the m2e-wro4j connector.
is always invoked on clean builds
updates the output folders so the changes can be visible directly in Eclipse and deployed directly via WTP if needed
automatically translates ${project.build.directory}/${project.build.finalName}/ output directories to ${project.build.directory}/m2e-wtp/web-resources/ if m2e-wtp is detected
Provides a wro4j-maven-plugin template, available on ctrl+space in the pom editor, in the <plugins> section :
Using the above wro4j-maven-plugin configuration, and provided you have an wro.xml descriptor under src/main/webapp/WEB-INF, you can see in the following example the 2 css files are combined and minified into one all.css file under /target/m2e-wtp/web-resources/resources/styles/ and the javascript file is minified under /target/m2e-wtp/web-resources/resources/styles/all.js
19/01/2012 Important update : the github repo was transfered to the jbosstools organization under https://github.com/jbosstools/m2e-wro4j/. You must manually update your upstream repository url.
Maven Integration for Eclipse WTP 0.14.0, a.k.a m2eclipse-wtp, a.k.a m2e-wtp is out the door. This new release brings its share of new features and enhancements, as well as a bunch of bug fixes. The complete release notes are available here.
m2e-wtp 0.14.0 works with Eclipse Helios and Indigo, requires at least m2e 1.0 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 : Window > Preferences > Maven > Discovery > Open catalog
So what's new and noteworthy in 0.14.0? Let's see :
New support for Application Client projects
Application Client packaging has been introduced with the new maven-acr-plugin. Support for app-client type dependencies has been added in maven-ear-plugin 2.6. Since Application Client projects are natively supported in WTP, we added a new configurator for app-client projects. When an app-client project is imported / configured via m2e, the Application Client Facet will be automatically installed, its version inferred from the contents of META-INF/application-client.xml. Filtering of the deployment descriptor is supported.
If a project contains a META-INF/web-fragment.xml in it's compilation output folder, the Web Fragment Facet is automatically installed upon maven project configuration (the Utility Facet is removed if necessary). Note that, as per the Java EE6 spec - and WTP is very picky about it-, Web Fragment projects *must* use Java 1.6. Failure to comply will fail the configuration and an error marker will be displayed.
The use of target/m2e-wtp/web-resources is now optional
On some occasions however, having target/m2e-wtp/web-resources/ might cause some troubles (incompatibilities with WTP editors, IBM RAD, using Servlet.getRealPath(...) in your code).
As a workaround, you can choose to not use target/m2e-wtp/web-resources/ and generate the pom.properties and MANIFEST.MF files in your source directory instead (It'll be your responsibility to add these files to your SCM ignore list).
In order to remove target/m2e-wtp/web-resources/ from the list of deployed folders, you need to change some preferences :
on your project only : right-click on the project > Properties > Maven > WTP : check "Enable Project Specific Settings" and uncheck "Maven Archiver generates files under the build directory"
on the whole workspace : Window > Preferences > Maven > WTP : uncheck "Maven Archiver generates files under the build directory"
Please note that this setting will be overridden if web resource filtering is in use, that is if the maven-war-plugin configuration declares <webResources> or sets <filterDeploymentDescriptor> to true. The reason is simple : you don't want to see your source files overwritten by the filtering mechanism (and it would also lead to some not-so-funny build loops).
Custom file name mapping for web project dependencies
The trick here is, in order to support non default filename mappings of dependencies listed in the Maven Library, the artifact is copied to the build directory (the target/ folder by default) under its new name. So if you happen to run a clean build of your project, wiping out that directory, you will need to manually run "Maven > Update Project configuration" on your project.
Option to not publish overlay changes automatically
In order to support publishing of overlay changes automatically, m2e-wtp aggressively cleared the cache of the servers your application is deployed to. However, The overlay feature still being in an experimental state, we decided to be more conservative with regard to server publishing, so a new "Automatically republish servers on overlay modification" preference has been added to Window > Preferences > Server > Overlays.
Overlays support is not bound to Maven, that's why it's under the Server preferences.
Support for the new tag="defaultRootSource" introduced in WTP 3.3.1
When several source folders are declared in the .settings/org.eclipse.wst.common.component file, WTP prior to 3.3.1 (Indigo SR1) tended to generate files (web.xml, faces-config.xml, ...) in the first folder it found. Since web projects define target/m2e-wtp/web-resources as the first source folder (target/m2e-wtp/ear-resources/ for EAR projects), that would cause some issues. In WTP 3.3.1, a new tag has been introduced, designed to indicate which source folder should be used by default, when files need to be looked for / generated. m2e-wtp now adds this tag when WTP 3.3.1 is installed :
As many projects, unfortunately, m2e-wtp doesn't shine in the documentation area. I've been using the github Wiki (https://github.com/sonatype/m2eclipse-wtp/wiki) to start a relatively modest FAQ. I'm planning on adding more content in the near future, but I'm also hoping the community at large will want to contribute some docs of its own. You just need a github account to be able to edit the Wiki.
In order to fix this issue, the code responsible for generating the MANIFEST.MF for all projects had to be integrated into the mavenarchiver feature.
That means m2e-wtp 0.13.1 now requires the installation of mavenarchiver from the m2e-extras update site. It will be discovered automatically from the new m2e-wtp update site, hosted by Red Hat, so it will be completely transparent for new users.
However, please note that the mavenarchiver feature replaces the pomproperties one, so the pomproperties must be uninstalled before upgrading m2e-wtp.
Thus, the preferred ways to install m2e-wtp remain :
1) Import existing Java EE projects into the workspace; You'll be proposed to install the m2e-wtp plugin :
click on Finish and the installation will proceed. Your projects will be imported but the workspace will have to be restarted.
2) Go to Window > Preferences > Maven > Discovery and click on "Open catalog". Select m2e-wtp and proceed with the installation.
While reviewing the installation details, you can see that mavenarchiver 0.14.0 will be found and installed automatically (provided there is not a more recent version already installed)
UPDATE (03/08/2011) : m2e-wtp is now also available from the Eclipse Marketplace. However, it seems some people are unable to install it directly. Please note that m2e-wtp requires m2e 1.0. So, if it's not installed already, Eclipse must be able to find it in the available update sites.
The change in m2e's namespace (org.maven.ide -> org.eclipse.m2e) between m2e 0.12.x and 1.0 renders updates impossible from m2e-wtp 0.12.x to 0.13.x. Thus you have no choice but to uninstall m2e < 1.0 and m2e-wtp < 0.13 before proceeding with m2e-wtp 0.13.x's installation.
So, Eclipse 3.7 a.k.a. Indigo has been released. This year, 62 Eclipse projects were made available on the same day. Part of the release train is M2E 1.0.0, which succesfully graduated from the Eclipse incubator. Congrats to all the teams involved!
m2e-wtp 0.13.0 is finally available as well. Last minute bugs prevented an earlier release and made our lives a bit difficult, but thanks to Igor Fedorenko, we made it. As you will discover, the WTP integration with Maven is thighter than ever! The complete release notes are available here, but let's take a quick look at what's new and noteworthy :
Discovery / installation
Once m2e is installed, there are several ways to install m2e-wtp. First you need to wipe the m2eclipse-extras update site from your memory (and eclipse), it only contains m2e 0.12.0 compatible plugins :
Finally, after all these years, m2e-wtp offers support for maven war overlays. The idea is to share common resources between several web applications. One use case could be to easily share logos, style sheets etc... in a corporate environment. All you need to do is declare in your web application pom.xml a dependency to another war artifact.
By default, all the contents of the overlaid artifact will be copied to the deployment directory of the web application, minus the MANIFEST.MF. The resources of the web application take precedence, in case of duplicate files.
If your project depends on a war archive (from your local repository), that dependency will be unzipped under target/m2e-wtp/overlays/<dependency>/ before being deployed to your server, according to the overlay configuration (you can select what files are included/excluded). For instance :
... won't deploy the jars from overlaid (project or archive)/WEB-INF/lib
If the dependency is another web project in your workspace, the deployed resources will be dynamically determined from the overlay configuration and any file changed in the overlaid project will be automatically redeployed to the target server.
Below is an example where the "war" project depends on an "overlaid" war project and hudson-war-2.0.1.war(before you asked, it's because this one is available in central). The images/hudson.png file is present in both overlay artifacts. The file is picked from "overlaid", since it's declared first in the pom. The deployed "war" project is a fully fledged CI server
As of now, unsupported features of war overlays are :
- filtering
- exclusions of resources from the main project (defined as <overlay></overlay>)
There's plenty of room for performance optimizations, and it still needs to be tested "on the field" so please, please, do not consider this feature as production ready, it's still experimental.
Also note that the WTP overlay metadata format (in .settings/org.eclipse.wst.common.component) has changed and is incompatible with older development builds of m2e-wtp 0.13.0. So if you used previous nightly builds, you should reimport your projects without their eclipse metadata (.project, .classpath, .settings/)
Removal of WTP classpath libraries
Since its infancy, m2e-wtp suffered from outstanding classpath resolution issues when unit tests were being run. It turned out some dependencies were being leaked by the WebApp and EAR classpath libraries, installed by default on Java EE projects. Having these libraries also required extra code complexity to move workspace dependencies from one library to the other. In m2e-wtp 0.13.0, a rather radical solution was taken : remove these WTP libraries after they're being automatically added by WTP. Guess what? it solved all the classpath issues occurring during tests and simplified the code. So from now on, you will just see the following libraries in the project explorer
:
'Deployed Resources' node in the Project View
Previous m2-wtp versions displayed a Web Resources node, for Web projects, or Application Resources for EARs, in the Project View. These nodes aggregate the content that must be deployed on the server / packaged in the final archive. A Web Resources node is already provided by JBoss Tools for projects having the JSF Facet installed. So, in order to avoid confusion, the nodes contributed by m2e-wtp have been renamed more appropriately to Deployed Resources :
Maven-generated MANIFEST.MF
Up until now, in m2e-wtp, the manifest was generated "manually" using WTP's API, for web projects only. In the process, the man
ifest 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, the 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 :
Finally, we tried to delete all MANIFESTS.MFs automatically generated by WTP. So hopefully, your source control shouldn't be polluted anymore.
Support for EAR Resource filtering
m2e-wtp now supports EAR resource filtering, pretty much the same way Web projects do. Just add the filtering attribute to your maven-ear-plugin configuration :
Filtered resources are generated under target/m2e-wtp/ear-resources/
Dropped support for Eclipse 3.5 and older versions
In order to support war overlays, m2e-wtp 0.13.0 is taking advantage of several APIs that were made available in Eclipse 3.6 ( Helios). The direct consequence is it's not longer compatible with Eclipse 3.5 (Galileo) based platforms and of course older versions. However it's been tested against Eclipse 3.6 and 3.7 on the continuous integration server at JBoss.
Now, what next?
Well, we're gonna see how the overlay support stands in the wild. If necessary, one or more 0.13.x bugfixes can be made available "quickly". One of the problem that delayed this release is a conflict between m2e-wtp and the pom properties configurator. This lead us to remove the latter from m2e marketplace catalog to avoid confusion. I hope we can find a solution quickly in order to restore that plugin in the marketplace.
Next version (0.14.) should include Dali support, Application Client packaging support, bug fixes and more...
So, thanks to Igor Fedorenko's last efforts, m2eclipse-wtp 0.12.0 is finally out, (update site available at http://m2eclipse.sonatype.org/sites/m2e-extras), bringing the WTP integration with Maven to a whole new level. The complete release notes are available here. However, I wanted to highlight some of the most notable features in this new version, so let’s take a quick tour :
On-the-fly web resource filtering
Maven has this interesting concept of web resource filtering : basically you can add resources existing in non standard directories, into your final web application. Moreover, you can filter these resources to apply, for instance, specific application configuration depending on a maven profile : you can activate some debug options in your web.xml, define development specific parameters in your spring configuration files, use a different css color scheme when you work locally and so forth. Supported maven web resource filtering features are :
inclusion/exclusion of resources
filtering (not activated by default)
target path (root of the web application by default)
possibility to use specific properties file filters
Here is a sample of maven-war-plugin configuration filtering any xml files under src/main/webapp, using an external filter file :
Note that after adding the webResource configuration to your pom.xml, you need to update the Maven project configuration.
m2eclipse-wtp 0.12.0 not only supports these features from maven, but goes one step further and brings you on-the-fly filtering : as soon as you save a file included in the <webResources> configuration from the maven-war-plugin, filtering is triggered automatically. Couple that with WTP’s hot redeployment capabilities, and you can see your changes by just reloading the affected pages in your browser.
OK, to be fair, that depends on the changed files, actually. If you change the content of your web.xml, or some spring config files, chances are you’ll have to restart your application or the server for the changes to be taken in consideration. The filtered resources are copied to the project build directory, under m2e-wtp/web-resources. You can view the content of this folder directly from the Project Explorer view in eclipse, under the Web Resources Node. You can open and compare side by side a raw file and its filtered version, as shown in the following screenshot.
In the previous example, the dev profile, activated by default (see lower right panel) determines which filter file must be used during filtering. In this case, we want to active some debugging options. The index.jsp page, shown in the browser in the lower left panel, displays the computed values of the different context-params from web.xml.
Now after changing the active profile (due to a bug in m2e-core 0.12.0, the pom.xml needs to be saved twice for the change to be detected, but this has been fixed in m2e-core 0.13.0) and after restarting tomcat (it doesn't restart the application upon web.xml changes), you'll notice the web.xml values are updated, values are taken from another properties file.
Context root customization
By default, the web project's context root is resolved from the <finalName> value resolved from the pom.xml. In the following example, the example-web project will be accessible at http://localhost:8080/example/, according to the finalName value :
However, you can customize the context root used in WTP by setting a custom property in your pom.xml, for instance, if you need to use "/" as your context root, just add <m2eclipse.wtp.contextRoot> in your properties and update your maven project configuration :
When restarting tomcat, the context root change will be detected and tomcat will ask to update its configuration. Now the same application is accessible at http://localhost:8080/
Java nature no longer added to EAR projects
The java nature was wrongly added to EAR projects. This is no longer the case. Moreover, existing Java nature will be automatically removed from existing EAR projects upon update project configuration.
Generation of application.xml outside the source folders
Since m2eclipse added support for EAR projects in 0.9.8, many users complained the deployment descriptor was generated under the source folder, under version control. Since application.xml (and jboss-app.xml) can be generated by maven automatically, there is no need to pollute the source folder right? Starting from m2eclipse-wtp 0.12.0, the deployment descriptors are now generated under <build directory>/m2e-wtp/ear-resources. Similarly to the web projects, a new Application Resources node is now displayed in the Project Explorer view, showing you which EAR resources will be deployed/exported.
If, for some reason, one would still want to generate the deployment descriptors under the source folder (src/main/application by default), then you could right click on the project, open the project Properties and go to the Maven > WTP integration page. There, after enabling specific project configuration, you can choose to NOT use the build folder to generate application.xml.
The same setting can be enabled globally for all EAR projects in the workspace by opening the Preferences > Maven > WTP Integration
After validating your choice, all EAR projects in the workspace will update their configuration, if you choose so.
Support for the no-version file name mapping in maven-ear-plugin
maven-ear-plugin 2.5 introduced a new file name mapping strategy, namely no-version, that remove the version suffix from all EAR deployed dependencies. All you need to do is add the following configuration to your maven-ear-plugin configuration :
Then you can check in the Project Explorer view, under the Deployment Descriptor node, all dependencies' names under the Bundle Libraries and Modules are updated :
Increased stability
Many users, over the years, experienced random crashes during project import or configuration update, or saw test resources being deployed with their applications. All these issues could be linked to one root cause : some WTP projects were missing a crucial element : the org.eclipse.wst.common.modulecore.ModuleCoreNature nature in their .project. The root cause of this "corruption" is still unclear, this is probably caused by some race condition, but unfortunately, this has proved impossible to reproduce with test projects.
m2eclipse-wtp 0.12.0 actually workarounds this issue : if the ModuleCoreNature is missing from WTP projects, it's automagically added to fix the projects, under the hood. Hopefully, this should fix most of the crashes users occasionally experience.
Now, what next?
m2eclipse-wtp 0.12.0 is the last version supporting Eclipse 3.5 (Galileo) based platforms. Next 0.13.0 version will be aligned with the new, revamped m2e-core 0.13.0 (= future 1.0) and will be released at about the same time frame as Eclipse 3.7 Indigo (late june). The next big thing is the added support for war overlays, the single most requested feature in m2eclipse-wtp. If you like to live on the bleeding edge, you can already try the latest development builds, available under https://repository.sonatype.org//content/sites/forge-sites/m2eclipse-wtp/0.13.0/N/ (use the latest directory as your update site).
One last thing : all this sweetness would not have been possible if I wasn't working full time on m2eclipse-wtp. Fortunately, Max R. Andersen got me a job in his JBoss Tools and Developer Studio team, and allows me to spend a considerable amount of time playing with my favorite toy of the moment :-) Thanks a bunch Max!!! Also big thanks to Eugene Kuleshov, Igor Fedorenko and Jason Van Zyl who gave me the chance to get involved in m2e(clipse).
