Skip navigation

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 :


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.





New support for Web Fragment projects

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

Remember, target/m2e-wtp/web-resources/ is used to allow the deployment of automatically generated web resources with WTP.

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 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

Since the maven-war-plugin allows file name customization for librairies and TLDs, based on patterns (, we added the the same feature in m2e-wtp. That will allow you to use a version-less name mapping for dependencies, like :











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 :


<project-modules id="moduleCoreId" project-version="1.5.0">
    <wb-module deploy-name="web-0.0.1-SNAPSHOT">
        <wb-resource deploy-path="/" source-path="/target/m2e-wtp/web-resources"/>
        <wb-resource deploy-path="/" source-path="/src/main/webapp" tag="defaultRootSource"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
         <property name="context-root" value="multi-web"/>
        <property name="java-output-path" value="/multi-web/target/classes"/>


A bit of documentation

As many projects, unfortunately, m2e-wtp doesn't shine in the documentation area. I've been using the github 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.



As always, if you find any issue, please open a bug report at (and don't forget to attach some test projects).


Happy coding.



Whether Forge Tools is male or female can possibly be a source of animated debate but under the motto 'She Comes in Colours Everywhere' we have added support for colours in the Forge console that comes with JBoss Tools. The result looks like the screenshot below.


An obvious improvement is to let users customize the used colours through the Eclipse preferences. This is the planned for subject of JBIDE-9746. In the meantime you can already enjoy the wonderful defaults! ;-)




It's time for a new fresh milestone update of JBoss Tools:


3.3 M3 (Greased Lightning)

[Download] [Update Site] [What's New] [Forums] [JIRA] [Twitter]



JBoss Tools is a set of plugins for Eclipse that complements, enhances and goes beyond the support that exist for JBoss and related technologies in the default Eclipse distribution. For this release we continue to move Maven, CDI, Java EE support forward and also add in a few new "surprise" features.



As always, get and install Eclipse 3.7 (Indigo) JEE bundle - with the JEE bundle you majority of the dependencies letting you save bandwidth:


Once you have installed Eclipse, you either find us on Eclipse Marketplace under "JBoss Tools (Indigo)" or use our update site directly.


The updatesite URL to use from Help > Install New Software... is:

Maven Profile Selection

In this release we've therefore included an UI which allows you to easily set/change the profiles on single and multiple projects.


This is especially something that becomes useful when you use Arquillian where it is a common practice to use Maven profiles to toggle the various dependency sets for each server you wish to test against.


It works by you selecting the relevant project(s), press Ctrl+Alt+P or use Maven > Select Maven Profiles... and a dialog box appears allowing you to enable/disable the available profiles for the project(s):




Easier Remote Debugging

Ever been tired of having to manually configure ports, projects and source path lookups for debugging on Remote Applications in Eclipse ?


We are, especially after we learned that JVM's running on Hotspot provides API to discover such applications and allow for easy configuration of your debugger. In this release we've thus added a command available from Debug As... > Remote Java Application... in the context menu on any set of resources.


Once you select this command, we use the Hotspot API to discover the remote running applications, allows you to select which you application want to connect to and then we do the tedious work of configuring the ports, names and source code lookups (including maven dependencies if applicable) for your Remote debugging.



No need for manual tweaking anymore.


Thanks to Aslak Knutsen for bringing us the idea and initial code to make this happen!


Running Server Detection

The server adapters now attempt to detect if a server is already running to avoid port conflicts and UI inconcistencies. If a server is detected running you are shown a dialog allowing you to choose to either have the server adapter assume it is already running or force the launch anyway.



CDI & Seam Solder

The CDI tooling adds a bunch of quickfixes to have JBoss Tools fix common issues. To aid in searching and navigating your CDI application, Find References (Ctrl+Shift+G) will now show the full list of injection points and EL usage of your beans and Seam Solder and Config annotations and XML now have easy hyperlink navigation to it's declarations.


The JSF tooling now detects @ManagedBean annotations. This avoids false warnings/errors when importing JSF 2 examples. Do consider using @Named instead for better integration into the JavaEE stack.


SAR Projects

For a long time we have been asked about providing support for SAR style projects for use on older versions of JBoss AS. This style of project packaging is now supported both in pure WTP style projects and via Maven.


GWT Tools are back

Since last time, Google released their GWT eclipse plugin in a version that supports Eclipse 3.7 allowing us to reenable the GWT Tools.


And more...

There are additional bugfixes and more features to browse over at What's New & Noteworthy


Like the new features ? Leave a comment to let us know!


And by all means,

Have fun!

Versions for large multi-module osgi projects

Recently I went through JBoss Tools main source code base and fixed a few long standing issues that had made it cumbersome to manage versions over the years. This blog tries to explain what we changed, why and how Tycho helped.

Tycho Version Plugin

Maven has it’s own versions plugin but it only takes care of version references in pom.xml, it does not consider osgi/p2 related references. Tycho therefore has it’s own versions plugin.

Unfortunately there aren’t alot of documentation for this plugin, but by poking to Sonatype, follow the tycho mailing list and looking at a few hints out there I managed to get the it working. Here is my attempt to make the world more aware of the Tycho Version plugin.


The core command for Tycho Versions plugin are executed in your Maven module that represents your plugin/features. The Tycho Version plugin command looks like this:

mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=<version>


Here <version> is the version number you want for your plugins, i.e. 1.2.3.GA. If you use 1.2.3-SNAPSHOT the plugin will use 1.2.3.qualifier in the places necessary (i.e. in and feature.xml).


The beauty of this plugin is that with a single command you can update your plugin, features, product and updatesite references.


No manual tweaking required, except that to use it effectively your pom.xml’s should follow a few maven conventions.


That last part is what kept us in JBoss Tools to use this command until recently.


Why you ask ? Well, read on…

Maven Parent/Child relationships

The reason we couldn’t use the tycho version plugin previously was that we had the following layout for each of our modules: 



Each top level module has a set of submodules: plugins, tests, features and site (there are also a doc module but that is for another blog).


Each of these submodules can have children, for plugins that are all the individual plugins the main feature will include, tests are the plugin tests and so forth.


That parent represents the parent pom where the shared build configuration for JBoss Tools is stored - we use that to avoid repeating the build instructions in all 350+ buildable units.


But there is a big problem with this structure.


First of each artifact have a manual maintained version section, but do you notice all those thick red outlined lines going to the Parent from each leaf plugin, feature, etc. ?


Those red lines illustrates that each child leaf point directly to the main parent pom which makes it possible to have the build configuration in one central place but it also means that everytime we update the parent pom version we have to change it in each and every node (for us that is 605 locations).


It also have the consequence that even though we have this nice modular division of each module into tests and plugins there is not a place to store module or submodule specific settings for our builds - that all have to take place in each leaf plugin instead of being just stated in one place.


Thus to make this sharing easier and to make it more explicit what structure is actually being versioned with the Tycho module Denis Golovin and I did a few pom refactorings.



Notice the difference ?


Each “sub-node” now uses their actual structural relative parent as the pom parent (red lines) and only the top level module actually points back to the main JBoss Tools parent module (blue line).


This has the following positive features:

  • you can stand in the root of a module and run mvn clean install and it will build the whole module
  • you can override/customize a build locally for a module or submodule
  • maven tycho version plugin will be able to easily version this module on its own


The last optimization I did lately was that now that we have this natural structure between parent and child setup we can remove the child modules redundant version info from the pom.xml’s. We unfortunately still have to list the full version info for the parent but with the Tycho versions plugin this becomes trivial to maintain.

The Dirty Details

The essentials parts of the structure is as follows (using hibernatetools as reference):

Module pom:

<project ...>
            <!-- the only reference to root build parent from a module -->
    <!-- the only place the module version number needs to be in a pom.xml for a module -->

Sub-Module pom:

<project ...>
            <!-- this section is maintained by the versions plugin --!>


…and finally the actual plugin/feature pom’s:

<project ... >


Notice how this setup makes the configuration at the plugin level very concise (or at least as concise as Maven allows them to be). Only if your plugin has custom build logic do they need to be different.


With this setup we can now easily customize our builds at a module level and easily bump our versions number across all the osgi/p2 artifacts within the module.


Meaning if I use the Tycho versions plugin to bump a module to 3.5.0, by default everything in that module gets bumped to 3.5.0, no matter if they have changed or not.


Purists of osgi might claim that is a bad practice and you should only bump the versions of the plugins that actually received changes and in principle I agree with them, but…


…JBoss Tools consists of about 202 plugins and 100 features each with their own feature.xml, MANIFEST.MF and when we included Tycho or rather Maven in the mix they also each have a pom.xml.


Add in the various updatesites, and other artifacts and just in the main source code tree of JBoss Tools it all adds up to us having at the current time of writing 628 versionable artifacts.


That is alot of versions to keep track of and ensure is uptodate.


Until now we have been maintaining the versions of these artifacts manually by hand and just as a precaution we (as many others in osgi/p2 land) do our builds with a .qualifier as the last part of the version number. This ensure the version number is always higher than the previous build. If we don’t, then p2 won’t install the newest build.


This actually means that if you don’t realize it then you can easily stay on version 1.0.0 for your plugins forever and ever - no users will complain since they can always get the the newest updated version.


The problem of being blind to versions of course show up when you start having multiple branches and even more so when you try to build up API plugins and want to ensure you are using the right compatible version - and here relying on the “random” qualifier string becomes unmanagable.


With a handful of plugins it’s “easy”, but with 628 artifacts it can become rather chaotic.


Thus I’ll argue its better to do it on the module level which reduces the versionable artifacts to 42 in our case - a much more managable number and much simpler to handle and understand for both developer and user IMO.


Notice, that if you are in a situation where you need to manually version specific plugins then you simply set the version explicitly for those plugins/features and Tycho versions plugin will not change them if they are not the same as the module pom.


That is another thing I like about this setup


- it allows you to do the most manageble thing easily, and if you need the full control you can do that for just the parts you wishes it for.


What do you think ?


Have you solved this problem differently/better/worse ?