JBoss Tools

12 Posts authored by: Fred Bricon

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

One more for the road!

Developer Studio: [Marketplace] [Download] | Tools: [Marketplace] [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 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 :

better-angularjs-support.png

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

 

Fred Bricon

 

http://twitter.com/fbricon

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

Hop in the cloudmobile!

Developer Studio: [Marketplace] [Download] | Tools: [Marketplace] [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 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.

CreateFileHyperlink.png

Angular.js attribute content assist

 

To aid in developing of Angular JS applications we've added content assist for ng-* attributes.

ng-ca.png

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.

multi-domain-in-explorer.png

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.

 

Happy Holidays and remember to Have Fun

 

Fred Bricon & Max Rydahl Andersen

 

http://twitter.com/fbricon

 

http://twitter.com/maxandersen

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

To Infinity and Beyond, but Mobile first!

Developer Studio: [Marketplace] [Download] | Tools: [Marketplace] [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 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:

http://download.jboss.org/jbosstools/updates/integration/kepler/integration-stack/aggregate/4.1.0/

 

Performance and stability improvements

 

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 worked really hard to fix more than 1600 bugs and feature enhancements into this release.

 

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 :

open-with-livereload.png

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

http://docs.jboss.org/tools/whatsnew/images/LiveReload_open_in_web_browser_via_qrcode-dialog.png

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 :

http://docs.jboss.org/tools/whatsnew/jst/images/4.1.0.Alpha2/lf.png http://docs.jboss.org/tools/whatsnew/jst/images/4.1.0.Beta1/set.png

Alexey Kazakov recorded a video to show it in action.

 

BrowserSim goodies

 

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

browsersim-firebug.png

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.

 

Carsten Pfeiffer did an awesome contribution and made this happen. If you're using Windows 64 bit, and if you follow the JBoss Tools Visual Editor FAQ link, you will be told to try to install XULRunner from http://download.jboss.org/jbosstools/builds/staging/xulrunner-1.9.2_win64/all/repo/

 

Hopefully you should see the following, before and after installing the proper XulRunner version :

http://docs.jboss.org/tools/whatsnew/vpe/images/4.1.0.Beta1/missing-xulrunner.png http://docs.jboss.org/tools/whatsnew/vpe/images/4.1.0.Beta1/vpe-win64.png

We would love to hear if this works for you on Windows 64-bit or if you still see problems.

 

You can give your feedback on this bug

 

Hybrid Mobile via Apache Cordova (Experimental)

 

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.

 

http://docs.jboss.org/tools/whatsnew/aerogear/images/runConfigs.png

 

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)

http://docs.jboss.org/tools/whatsnew/browsersim/images/4.1.0.Beta1/CordovaSim-demo.png

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

 

new-forge-based-wizards.png

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

arquillian-junit-1.png arquillian-test-3.png

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.

http://docs.jboss.org/tools/whatsnew/openshift/images/publishing-to-openshift.png

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.

http://docs.jboss.org/tools/whatsnew/openshift/images/restart-application.png

 

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.

http://docs.jboss.org/tools/whatsnew/openshift/images/advanced-source-code.png

 

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.

http://docs.jboss.org/tools/whatsnew/openshift/images/configre-markers-wizard.png

 

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.

http://content.screencast.com/users/fbricon/folders/Jing/media/679e2a00-11e7-4f3c-910a-1cc1d0fcf79a/2013-07-19_0953.png

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.

new-server-adapters.png

 

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 :

automatic-source-lookup.png

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 :

edit-maven-repositories.png

 

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.

 

Have fun!

 

Fred Bricon

 

http://twitter.com/fbricon

With bits of JBoss Tools in it

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.

M2e-wtp-optional-configurator-preferences.png

 

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

 

You can also install m2e-wtp from the  Eclipse Marketplace.

 

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.

 

Enjoy,

 

Fred.

https://twitter.com/#!/fbricon

Finally!

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.

 

http://wiki.eclipse.org/images/a/a0/M2e-wtp-0160-convert-web-part03.png

 

Take a look at the New and Noteworthy and changelog to learn more about what's in for you.

 

Installation and gotchas

m2e-wtp requires at least m2e 1.1 (though 1.2 is recommended) and can be installed from its p2 update site : http://download.eclipse.org/m2e-wtp/releases/ or the  Eclipse Marketplace.

 

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.

 

Enjoy,

 

Fred.

https://twitter.com/#!/fbricon

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

 

m2e-apt supports both annotation processing set on the maven-compiler-plugin or the maven-processor-plugin (the latter takes precedence over the former).

 

For example, to enable the JPA modelgen annotation processor, you can either set :

 

<plugin> 
    <artifactId>maven-compiler-plugin</artifactId> 
    <version>2.4</version> 
    <configuration> 
        <source>1.6</source> 
        <target>1.6</target> 
    </configuration> 
    <dependencies> 
        <dependency> 
            <groupId>org.hibernate</groupId> 
            <artifactId>hibernate-jpamodelgen</artifactId> 
            <version>1.2.0.Final</version> 
        </dependency> 
    </dependencies> 
</plugin> 

 

or

 

 

<plugin> 
    <artifactId>maven-compiler-plugin</artifactId> 
    <version>2.4</version> 
    <configuration> 
        <source>1.6</source> 
        <target>1.6</target> 
        <compilerArgument>-proc:none</compilerArgument> 
    </configuration> 
</plugin> 
<plugin> 
    <groupId>org.bsc.maven</groupId> 
    <artifactId>maven-processor-plugin</artifactId> 
    <version>2.0.5</version> 
    <executions> 
        <execution> 
            <id>process</id> 
            <goals> 
                <goal>process</goal> 
            </goals> 
            <phase>generate-sources</phase> 
        </execution> 
    </executions> 
    <dependencies> 
        <dependency> 
            <groupId>org.hibernate</groupId> 
            <artifactId>hibernate-jpamodelgen</artifactId> 
            <version>1.2.0.Final</version> 
        </dependency> 
    </dependencies> 
</plugin> 

 

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.

 

m2e-apt.png

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-prefs.png

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.

 

m2e-apt is available :

 

Source code is available at github. If you find any bug, please raise a ticket on m2e-apt's issue tracker.

 

Happy hacking,

 

Fred

https://twitter.com/#!/fbricon

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 :


 

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 :

component_patterns.png

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.

unsupported-dependency-type.png

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 :

 

Keep it up.

 

 

Fred.

https://twitter.com/#!/fbricon

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

 

<plugins>
  <plugin>
    <groupId>ro.isdc.wro4j</groupId>
    <artifactId>wro4j-maven-plugin</artifactId>
    <version>${wro4j.version}</version>
    <executions>
      <execution>
        <phase>compile</phase>
        <goals>
          <goal>run</goal>
        </goals>
      </execution>
    </executions>
    <configuration>
      <targetGroups>all</targetGroups>
      <destinationFolder>${basedir}/src/main/webapp/wro/</destinationFolder>
      <contextFolder>${basedir}/src/main/webapp/</contextFolder>
    </configuration>
  </plugin>
</plugins>

 

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 :

wro4j-template.png

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

wro4j-optimization.png

 

If you're interested in trying m2e-wro4j, you can install it from the following p2 update site : http://download.jboss.org/jbosstools/updates/m2e-wro4j/

 

 

Please be aware this initial version is really in its alpha stage (was coded in a day). Issues can be opened at https://github.com/jbosstools/m2e-wro4j/issues

 

For all your WRO4J or wro4j-maven-plugin specific issues, I strongly encourage you to :

 

Hope it helps.

 

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.

 

Fred

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.

 

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-acr-plugin</artifactId>
  <version>1.0</version>
  <extensions>true</extensions>
  <configuration>
    <archive>
      <manifest>
        <mainClass>foo.bar.appclient.Main</mainClass>
      </manifest>
    </archive>
    <filterDeploymentDescriptor>true</filterDeploymentDescriptor>
  </configuration>
</plugin>

 

appclient.png

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.

 

webfragment.png

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

 

war-preferences.png

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 (http://maven.apache.org/plugins/maven-war-plugin/examples/file-name-mapping.html), we added the the same feature in m2e-wtp. That will allow you to use a version-less name mapping for dependencies, like :

 

<plugin>

  <groupId>org.apache.maven.plugins</groupId>

  <artifactId>maven-war-plugin</artifactId>

  <version>2.1.1</version>

  <configuration>

    <outputFileNameMapping>@{groupId}@-@{artifactId}@.@{extension}@</outputFileNameMapping>

  </configuration>

</plugin>

 

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.

 

overlay-republishing-preference.png

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"/>
    </wb-module>
</project-modules>

 

A bit of documentation

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.

 

 

As always, if you find any issue, please open a bug report at https://issues.sonatype.org/browse/MECLIPSEWTP (and don't forget to attach some test projects).

 

Happy coding.

 

Fred.

https://twitter.com/#!/fbricon

As I mentioned in the previous blog post (http://community.jboss.org/en/tools/blog/2011/06/23/m2eclipse-wtp-0130-new-noteworthy), m2e-wtp had to be pulled out of the m2e marketplace, as it forced its installation for all non-WTP systems.

 

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 :

m2e-wtp-detection.png

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.

m2e-wtp-marketplace.png

3) Old school installation : Use this JBoss / Red Hat update site : http://download.jboss.org/jbosstools/updates/m2eclipse-wtp/ 

 

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)

m2e-wtp-installation.png

 

Other that the changes necessary to reinstate m2e-wtp to the m2e marketplace, There is only one other bugfix in 0.13.1, which fixes deployment of war archives overlays in Windows (https://issues.sonatype.org/secure/ReleaseNote.jspa?projectId=10310&version=11271).

 

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.

m2e can be installed from either http://download.eclipse.org/releases/indigo (for Indigo) or http://download.eclipse.org/technology/m2e/releases/ (for Helios and Indigo).

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.

(I hope I'm clear enough :-))

 

Enjoy,

 

Fred.

https://twitter.com/#!/fbricon

Embracing Indigo

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 :

 

IMPORTANT UPDATE : m2e-wtp has been temporarily removed from the m2e marketplace (http://dev.eclipse.org/mhonarc/lists/m2e-users/msg00938.html). Please consider option #3 while we're working on fixing the problem.

 

IMPORTANT UPDATE (02/08/2011) :the m2e marketplace issue is fixed with m2e-wtp 0.13.1 : http://community.jboss.org/en/tools/blog/2011/08/01/m2eclipse-wtp-0131-back-to-the-m2e-marketplace

 

1) Import existing Java EE projects into the workspace; You'll be proposed to install the m2e-wtp plugin :

 

m2e-wtp-discovery.jpg

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 and proceed with the installation.

 

3) Old school installation : Use this update site : https://repository.sonatype.org/content/sites/forge-sites/m2eclipse-wtp/0.13.0/S/0.13.0.20110623-0455/ 

 

IMPORTANT UPDATE 2 : m2e-wtp 0.13.1 is available from a new update site url (http://download.jboss.org/jbosstools/updates/m2eclipse-wtp/).

 

Experimental war overlay support

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.

 

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>foo.bar</groupId>
    <artifactId>war</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>war</packaging>
    <dependencies>
        <dependency>
            <groupId>foo.bar</groupId>
            <artifactId>overlaid</artifactId>
            <version>0.0.1-SNAPSHOT</version>
            <type>war</type>
        </dependency>
    </dependencies>
</project>

 

 

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 :

 

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.1.1</version>
        <configuration>
            <overlays>
               <overlay>
                  <groupId>foo.bar</groupId>
                  <artifactId>overlaid</artifactId>
                   <excludes>
                       <exclude>WEB-INF/lib/*</exclude>
                    </excludes>
                 </overlay>
            </overlays>
    </configuration>
</plugin>

 

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

war-overlay.jpg

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

classpath-containers.jpg

 

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

deployed-folders.jpg

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/

manifest-support.jpg

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>

 

 

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 :

 

<plugins>
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ear-plugin</artifactId>
    <version>2.6</version>
    <configuration>
        <filtering>true</filtering>
        ...
    </configuration>
  </plugin>
</plugins>

 

Filtered resources are generated under target/m2e-wtp/ear-resources/

ear-filtering.jpg

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

As always, if you find any issue or would like to see new useful features in m2e-wtp, please open a ticket at https://issues.sonatype.org/browse/MECLIPSEWTP

 

Enjoy,

 

Fred.

https://twitter.com/#!/fbricon

 

PS: Again, special kudos to Igor Fedorenko who supported me during this not-so-trivial release.

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 :

 

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.1.1</version>
        <configuration>
            <webResources>
                <filters>
                    <filter>src/main/filters/dev.properties</filter>
                </filters>
                <resource>
                    <directory>src/main/webapp</directory>
                    <filtering>true</filtering>
                    <includes>
                        <include>**/*.xml</include>
                    </includes>
                </resource>
            </webResources>
    </configuration>
</plugin>

 

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.

 

web-resource-filtering-profile1.jpg

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.

web-resource-filtering-profile2.jpg

 

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  :

m2e-wtp-context-root-finalname.jpg

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 :

 

<properties>
    ...
    <m2eclipse.wtp.contextRoot>/<m2eclipse.wtp.contextRoot>
    ... 
</properties>

 

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/

 

m2e-wtp-context-root-property.jpg

 

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.

ear-application-resources.jpg

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.

 

m2e-wtp-project-properties.jpg

 

The same setting can be enabled globally for all EAR projects in the workspace by opening the Preferences > Maven > WTP Integration

m2e-wtp-preferences.jpg

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 :

 

 

 

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ear-plugin</artifactId>
    <version>2.5</version>
    <configuration>
       ...
       <fileNameMapping>no-version</fileNameMapping>
       ...
    </configuration>
  </plugin>

 

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 :

ear-noversion-filenamemapping.jpg

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

 

Enjoy,

 

Fred.

Filter Blog

By date:
By tag: