Skip navigation
2011

Following the release of JBoss Tools 3.3M2 that was announced yesterday, this article highlights the main features provided by the new JAX-RS tooling which is part of this new milestone.

 

Installing the plugin

As explained in the announcement, the fastest and easiest way to get started with JBoss Tools is to download & install the Eclipse 3.7 (Indigo) JEE bundle. Once you have installed Eclipse, you use our update site directly.

 

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

 

http://download.jboss.org/jbosstools/updates/development/indigo/

Then, go to the "All JBoss Tools 3.3" section and select "JBoss JAX-RS Tools"

Capture d’écran 2011-06-30 à 22.05.46.png

Using a sample project

A quick way to get started with the tooling is to download the JBoss AS7 Quickstarts from their download page. Once you've unzipped the archive, import the "KitchenSink" project into your workspace using the Import > Existing Maven Project menu.

 

You'll need to install the m2eclipse plugin to import the project.

 

Capture d’écran 2011-06-30 à 22.52.57.png

 

Activating the support for JAX-RS

One way to activate support for JAX-RS in your project is to click on "Configure > Add JAX-RS 1.1 support..." in the project's contextual menu, which in turn will add the "JAX-RS Nature" to it.

jaxrs_install.png

 

 

If the project you're working on is a "Dynamic Web Project", you can also install the standard Eclipse "JAX-RS (REST Web Services)" Facet, which will in turn will add the "JAX-RS Nature" as described in the previous case.

 

jaxrs_facet.png

In both cases, a "JAX-RS Builder" will be added to your project.

 

Current features

In this milestone, the JAX-RS Builder offers the features described below.

Mapping of JAX-RS elements to the source

The JAX-RS Builder computes and keeps in sync' an im-memory metamodel of the JAX-RS elements of your project. The metamodel is reinitialized during a clean/full build of your project, and all kinds of changes to compilation units are applied to the metamodel.     

 

RESTful Web Services explorer

The RESTful Web Services outline in the the Project Explorer view is certainly the most attractive feature of this plugin, as it displays the resolved URI Path Templates based on the metamodel described above.

 

The URI Path Templates resolution works with both Methods and Submethods of Root Resources and Subresources. In addition, each node in the outline indicates the consumed and produced media-types and the Java method that would be called when a request matching the combo {HTTP Method + URI Path Template + Content Negociation}. Double-clicking on the elements of the outline opens the Java Editor to the associated location in the source code.

Capture d’écran 2011-06-30 à 23.14.50.png

 

Event tough the classes annotated with the @javax.ws.rs.ext.Provider are not shown on the Project Explorer's view yet, they are already taken into account by the JAX-RS Builder, so you can expect further features around those elements in the next releases.

 

Code completion for JAX-RS annotation values

Code completion for @javax.ws.rs.PathParam annotation value is available. The completion processor analyses the source of the Java Type to return proposals based on the @javax.ws.rs.PathParam annotations values both at the method and at the type levels. The additional information of each proposal highlights the part of the code from which the proposal was computed.

Capture d’écran 2011-06-30 à 22.57.51.png

Those completion proposals support the regular expressions, too.

 

Validation of JAX-RS constructs

The plugin currently validates that a method parameter annotated with @javax.ws.rs.PathParam annotation matches with the @javax.ws.rs.Path annotation value on the same method.

Capture d’écran 2011-06-30 à 23.00.26.png

 

 

That's it for now. Remember that the tooling is not yet complete but is very functional and we are looking forward to get feedback on its current functionality and what you would like to see in the future !

 

Have fun !

 

PS : as an individual contributor, I'd also like to thank the JBoss Tools team for the support and confidence they've put in the work I've done so far. As Max Andersen says, it's the way OSS works, and it's really great !

jbosstools_as7_logo.png

3.3 M2 (Rabbit Chaser)

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

 

We've worked around the speed bumps I talked about last time, and can now announce the release of JBoss Tools 3.3 M2, the first milestone that will work with Eclipse 3.7 "Indigo" and the just released JBoss "White Rabbit" AS 7 CR 1.

 

Note: Since this blog was written, AS 7 Final was released and is now available and works with JBoss Tools 3.3 M2 and higher!

 

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, in this release we are especially moving the AS 7 and CDI/Solder integration forward.

Installation

 

First off, go download & Install Eclipse 3.7 (Indigo) JEE bundle - you can use some of the other bundles too, but with the JEE bundle you save bandwidth and you'll have less problems getting the right dependencies.

 

Once you have installed Eclipse, you use our update site directly.

 

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

 

http://download.jboss.org/jbosstools/updates/development/indigo/

 

Important: If you are running on recent released Linux distributions or 64-bit distributions you might be bumping into an Eclipse 3.7 regression bug that prevents the visual page editor to load and result in a hard crash of the visual VM. To avoid this problem you can run eclipse with a property to disable the visual page editor.

 

eclipse -vmargs -Dorg.jboss.tools.vpe.loadxulrunner=false

 

Alternatively you can try using

http://anonsvn.jboss.org/repos/jbosstools/workspace/snjeza/swt.xulrunner.patch

as updatesite to install temporary SWT patch that works similar to the planned Eclipse 3.7.1 patch.

 

Where are my SOA Tools ?

We are working on splitting out the SOA functionality (Teiid, Modeshape, Drools and jbpm) from the core distribution since the SOA tooling historically are not following the same release cycle of the core and thus at times it is beneficial that they can release their final version a bit delayed from the core. That means that for this milestone the main updatesite does not contain SOA tools but will for now be on a separate updatesite.

 

JBoss Tools - SOA Tooling updatesite:

 

http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooling/

 

The final layout and distribution mechanisms might change as we collect feedback, but for now SOA is separate from the core.

 

JBoss Application Server 7

This morning JBoss AS 7 CR1 was released and JBoss Tools are ready to support it. The best way I can imagine showing what this means is by giving you this very short screencast showing how easy and fast AS 7 is and how easy it is to use when using from JBoss Tools.

 

 

 

Another additional new feature for this release is the option named "Do not exectue startup or shutdown commands".

 

dont-execute-start-command.png

This option allows you to start and stop your server outside of Eclipse but still be able to use the deployment, debugger and Run As.. features.

Ideal for when you want to run your own custom startup scripts and maybe even more interesting for remote servers where the server might be started/stopped by service scripts instad.

 

JAX-RS

Xavier Coulon contributed JAX-RS standard tooling to JBoss Tools shortly after M1 and I'm now very proud to include it in this milestone.

Xavier will be blogging about this shortly but in short it provides a explorer to navigate your JAX-RS resources and it comes with basic validation and code completion related to JAX-RS.

 

jaxrs_explorer.png

 

The tooling will evolve more over the upcoming milestones/betas; if you have input/questions we are very interested in hearing about it.

Context & Dependency Injection (CDI)

For this release the Seam Solder support is more complete by adding support for @Generic beans which is used by most Seam 3 and many CDI extensions out there to customize their framework CDI integration. This allows JBoss Tools to be more precise in its validation but also to provide better and improved content assist and navigation for CDI components.

 

Other extensions like Seam Config also got improvements and we now provide better validation of the Java backed schemas in the XML file format for CDI.

 

seam_config_validation.png

Maven & AS 7 Quick Starts

With the release of Maven Integration For WTP (org.maven.ide.eclipse.wtp) 0.13 a few days ago Maven works even better now together with Eclipse WTP projects - in particular, there are fixes concerning having manifest and other descriptors generated by Maven according to pom.xml and  much better handling of classpath which make this a huge improvement over previous versions.

 

On top of these enhancements we've added further automatic configuration of your projects based on your pom.xml and its dependencies making it super easy to import existing Maven projects using technologies like JSF, CDI and Hibernate.

 

This all is coming together with the AS 7 CR 1 release which comes with a set of Quickstarts and archetypes.

Both the quickstarts and archetypes will automatically get configured when you import them to have all the JBoss Tools enhancements ready for you to use.

 

Give them a try.

 

And more...

There are a bunch of other improvements in this release and you can see descriptions and screenshots in What's New

 

Over the next few days/weeks we will be blogging more about the new features and usecases this release of JBoss Tools and AS 7 enables.

 

Feedback

As always we crave for any feedback you can give, especially if you have a project that causes performance issues or wrong validations. We've done a lot of work testing but we are sure we haven't covered all possible combinations - if you find something we missed let us know!

 

Thanks, and now go chase that White Rabbit! with JBoss Tools!

 

Have fun!

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.

Update: JBoss Tools 3.3 M2 have been released that targets/supports Eclipse 3.7 making this blog out-of-date!

In about 24 hours or so Eclipse Indigo are going to push out their Indigo release train and its many users will bring all the Eclipse mirrors to a halt for the coming days.

 

The yearly release of Eclipse always generates alot of questions concerning if JBoss Tools will run on the latest and greatest version just released and i'm writing this blog so those that go look will have an answer.

 

The short answer is that you can use JBoss Tools 3.3.0.M1 release with Eclipse 3.7M6, last minute API changes makes it so you will see errors

if you try run M1 on Eclipse 3.7 final. If you really really want to to use Eclipse 3.7 final you can use our nightly build updatesite on your own risk but I do recommend you wait until we have JBoss Tools 3.3.0.M2.

 

We were planning on releasing on the same date as Indigo, but we have hit a few speedbumps on the last weeks of release lockdown making it so we will miss the Indigo release train.

 

The speed bumps is the release of JBoss AS 7 release candidate to be sure our new AS 7 Server adapter integration will work smoothly and we needed to implement a workaround for a hard-to-track regression issue with Eclipse SWT and XulRunner which causes crashes on newer Linux distributions.

 

We expect to have these fixed this week and expect to release JBoss Tools 3.3.0.M2 shortly there after.

 

I'll update this blog when release details becomes available.

 

Have fun!