1 3 4 5 6 7 Previous Next

JBoss Tools

121 posts

Shift Happens in the last planned milestone of JBoss Tools 3.3. Read on for more...

http://in.relation.to/service/File/10824

3.3 M4 (Shift Happens)

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

 

JBoss Tools is a set of plugins for Eclipse that complements, enhances and goes beyond the support that exist for JBoss and related technologies in the default Eclipse distribution.

 

This time around we are adding in a central hub for users called JBoss Central, support for OpenShift, some OSGi magic, Runtime downloads and more...

 

Installation

 

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

 

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

 

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

 

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


JBoss Central

First time you install JBoss Tools M4 you will be greeted with what we've named JBoss Central. JBoss Central is a hub for getting easy access to Project Wizards, Examples, jboss.org news and additional Eclipse plugin installation.

 

http://docs.jboss.org/tools/whatsnew/images/jbosscentraleditor.png

 

It will show up on every startup by default which if you don't want it can be disabled in preferences. The editor will also show up when there are new updates to JBoss Tools plugins installed.

 

If you want to open central later you can find it under Help > JBoss Central.

 

OpenShift Express

OpenShift Express by Red Hat provides free, auto-scaling platform-as-a-service for Java, Ruby, PHP, Perl and Python applications. Until now to use it you've had to use command line tools like git and rhc-* commands; with JBoss Tools support for OpenShift you can do all of the hard work in the comfort of Eclipse.

 

To get started use the OpenShift Express Application Wizard available from File > New > OpenShift.

 

http://docs.jboss.org/tools/whatsnew/openshift/images/applications.png

 

If you are a new user the wizard will walk you through the needed steps to setup an account, create domain and create applications.

If you are an existing user with existing applications it will allow you to log in, choose an application and import the project into Eclipse and in case of it being a JBoss 7 type application we will even setup a server for you in Eclipse server view that allows you to easily publish directly to OpenShift.

 

This publish is just a Git commit & push which you can also do from command line or manually via eGit in Eclipse - but with the server adapter integration you get a simple and easy way of doing it without having to deal with git manually.

 

Materialize Library

Eclipse likes to encapsulate jar library access in Classpath Container's and sometimes these classpath containers are great to begin with but for various reasons you might want to decouple your Eclipse projects from the plugin providing the classpath container or maybe you've used one of the great Project Examples or quickstarts we provide via JBoss Central but you don't want to use Maven to manage your libraries/build then this feature also comes handy.

 

We've added an experimental feature named "Materialize Library" which is available in the context menu of classpath containers in Eclipse.

 

http://docs.jboss.org/tools/whatsnew/core/images/materialize-lib-context-menu.png

 

Once you click that JBoss Tools will present you with a dialog asking where to put the libraries and once you press Ok your project will no longer be dependent on the classpath container, but instead have a copy of the jars and all configured as it was inside Java Build path still; allowing you to more easy build and migrate your project to another setup if need be.

 

 

Richfaces 4

We've implemented support in the visual page editor for the new and updated JSF components in Richfaces 4.

 

 

http://docs.jboss.org/tools/whatsnew/vpe/images/3.3.0.M4/8950.png

 

CDI & Seam Solder

The CDI tooling this time around continues to add more quick fixes, improved navigation and adds an "Open Named CDI Bean" dialog for easy lookup of named CDI beans.

 

http://docs.jboss.org/tools/whatsnew/cdi/images/3.3.0.M4/openNamed.png

 

It also adds support for the new package naming in Seam 3.1.Beta4 for the Solder and Config modules, while still maintaing support for previous Seam 3 releases.

 

Forge in Color

Forge console now has better editing, is now using color rendering and is made easily available with the new Ctrl+4 (or Cmd+4 on OSX) shortcut.

 

forge-tools.png

 

JBoss OSGi

The JBoss adapter now supports dragging Eclipse PDE (OSGi) projects to the server and it will use the default PDE export to create and bundle the archive.

 

Runtime downloads

JBoss Tools now provide easy access to download runtimes such as JBoss AS and Seam (more to be added in the future).

This feature are directly available from JBoss Tools Runtime Detection preference page.

 

http://docs.jboss.org/tools/whatsnew/as/images/runtimedownload1.png

or via use of Project Examples that requires a runtime.

http://docs.jboss.org/tools/whatsnew/images/jbosscentraldownloadas.png

 

The downloaded runtimes will be installed in a directory of your choosing and will be configured to be ready for use within Eclipse/JBoss Tools.

 

And more...

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

 

This is our last planned milestone, beta is next thus its time to make your voice heard and speak up if there are features that aren't giving you what you need.

 

Leave a comment to let us know!

 

And as always,

Have fun!

A couple of days ago somebody asked me how to use Forge after having installed the JBoss Tools nighty build. This is a valid question and indeed not so obvious at the moment. We don't want to overload the top level Eclipse menubar and toolbar so it is somewhat hidden until we find a good spot for the shortcuts. Suggestions are of course always welcome.

 

The Long and Winding Road

The normal way to start Forge is to start it by pressing the start toolbar button or choosing the start menu entry of the Forge Console View.

start_button.pngstart_menu.png

Now the question of course is how you can open this Forge Console View. This can be done by selecting the 'Forge->Forge Console' entry in the Eclipse 'Show View' dialog.

Show_View.png

Now the question of course is how you can open this fancy 'Show View' dialog. The long and winding road to do this would be to use the Eclipse menu bar and select 'Window->Show View->Other...'. Luckily there is a quicker alternative to do this last step only using your keyboard:

  • Windows and Linux: press Alt+Shift+Q and then another Q
  • Mac: press Option+Cmd+Q and then another Q

 

The Fast Lane

Even with this last keyboard trick this is a very long process and it would be good if there was a faster way to do it. The good news is that there actually is a shortcut. Earlier, we posted how to bring up a popup containing all the Forge commands applicable in the current context

  • Windows and Linux: Ctrl+4
  • Mac: press Cmd+4

Now if only we extended the functionality of this combination to startup Forge if it is not running? That is exactly what we did. Pressing the above key combination brings up a dialog if Forge is not running yet and asks you if you want to start it.

forge_not_running.pngPressing 'Yes' on this menu will start Forge, open the Forge Console View and bring this last view into focus. If the above combination does not work on your machine (because of a different keyboard layout) or if you would like to hook up this functionality to a different keystroke combo, you can do so by bringing up the Eclipse Preferences dialog:

  • Windows and Linux: choose 'Window->Preferences'
  • Mac: choose 'Eclipse->Preferences...' or press Cmd+, (that is Cmd and the comma).

preferences.png As you can see in the above screenshot, you can change the binding by selecting the 'General->Keys' entry and then look for the 'Forge Command List' command. Go into the 'Binding' field and choose your favourite keyboard combination.

 

The Result

Whether you take the long and winding road or the fast lane, the result should in both cases that you are seeing the Forge welcome banner and a prompt inviting you to enter your command of choice.

console_view.png

 

This is a work in progress. If you have any suggestions to make a better binding, or ideas about a proper perspective or menu that could be a home for this functionality, be my guest!

 

Cheers,

Koen

European conference season is about to start and I and others will be out and about talking about JBoss Tools and Friends the upcoming weeks/months. Here is an excerpt of those I'll be giving or attending:

 

Switzerland - Puzzle event & Neuchatel JBUG

Tuesday, 18th October at Puzzle Tech Talk 2011, I'll be giving a short introduction on the various flavors of Red Hat OpenShift.

 

Wednesday, 19th October at JBUG Neuchatel, Thomas Heute and I will be giving a more detailed look into using OpenShift Express for scripting languages and especially Java EE development on top of JBoss AS 7.

 

JUDCon, London

Monday, 31st October I get the pleasure to attend my first European JUDCon where I'll be taking the stage a few times:

 

14:30-15:15 - Making Examples accessible - talking about the rare subject on how you make your projects examples easy to use and install from both command line and IDE's. Cancelled.

 

19:00-20:00 - Emmanuel Bernard and I will host a live JBoss Community Asylum podcast from JUDCon inviting speakers and community members on stage to answer questions from the hosts and audience.

 

20:00-?? - Lightning talk showing five approaches to deploy to JBoss AS 7 in five minutes.

 

Do not forget to Register for JUDCon !

 

EclipseCon, Ludwigsburg

This year EclipseCon Europe will be celebrating 10 year annivesary of Eclipse and we'll have two talks there on Thursday, 3rd November.

 

11:30-12:00 Fred Bricon will be giving his Workaround Driven Development : How Maven integrates with Eclipse WTP talk where he will show m2e-wtp and talk about the challenges making it happen within the boundaries of Eclipse WTP.

 

15:30-16:00 I'm presenting on the Good, Bad and Ugly sides of using Tycho for building Eclipse plugins.

 

Devoxx, Antwerp

My favorite conference in Europe - primarily because of its awesome venue but also that I get to meet up with a large bunch of JBoss colleagues and community members.

 

Tuesday, 15th November at 13:00-13:15 I'm doing a Quickie talk covering how to Deploy JEE applications to OpenShift

 

You'll also find me hanging out/talking at the BOF's concerning JBoss technology: CDI, what comes next, JBoss Application Server 7 and Seam Gathering.

 

See you there!

For those interesting in stalking conference speakers and events I recommend checking out Lanyrd.com, been using it extensively to be able to write the above pretty fast You can see my lanyrd schedule here.

 

See you out there!

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

Koen Aers

Forge Tools: She's a Rainbow

Posted by Koen Aers Sep 20, 2011

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

forge_colors.png

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

 

Cheers,

Koen

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

grease_jboss_tools.png

3.3 M3 (Greased Lightning)

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

 

 

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

Installation

 

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

 

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

 

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

 

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


Maven Profile Selection

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

 

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

 

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

 

maven-profile-selection-single-project.jpg

 

Easier Remote Debugging

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

 

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

 

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

 

remote-debugging2.png

No need for manual tweaking anymore.

 

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

 

Running Server Detection

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

 

server-already-running.png

CDI & Seam Solder

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

@ManagedBean's

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

 

SAR Projects

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

 

GWT Tools are back

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

 

And more...

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

 

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

 

And by all means,

Have fun!

Versions for large multi-module osgi projects

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

Tycho Version Plugin

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

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

Usage

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

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

 

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

 

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

 

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

 

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

 

Why you ask ? Well, read on…

Maven Parent/Child relationships

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

 

modules_before_reorg.png

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

 

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

 

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

 

But there is a big problem with this structure.

 

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

 

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

 

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

 

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

 

modules_after_reorg.png

Notice the difference ?

 

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

 

This has the following positive features:

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

 

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

The Dirty Details

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

Module pom:

<project ...>
    ...
    <parent>
            <!-- the only reference to root build parent from a module -->
            <groupId>org.jboss.tools</groupId>
            <artifactId>org.jboss.tools.parent.pom</artifactId>
            <version>0.0.2-SNAPSHOT</version>
            <relativePath>../build/parent/pom.xml</relativePath>
    </parent>
    <groupId>org.jboss.tools</groupId>
    <artifactId>hibernatetools</artifactId>
    <name>hibernatetools.all</name>
    <!-- the only place the module version number needs to be in a pom.xml for a module -->
    <version>3.4.0-SNAPSHOT</version>
    <packaging>pom</packaging>
    <modules>
            <module>features</module>
            <module>plugins</module>
            <module>tests</module>
            <module>site</module>
   </modules>
</project>

Sub-Module pom:

<project ...>
    ...
    <parent>
            <!-- this section is maintained by the versions plugin --!>
            <groupId>org.jboss.tools</groupId>
            <artifactId>hibernatetools</artifactId>
            <version>3.4.0-SNAPSHOT</version>
    </parent>
    <groupId>org.jboss.tools.hibernatetools</groupId>
    <artifactId>plugins</artifactId>
    <name>hibernatetools.plugins</name>
    <packaging>pom</packaging>
    <modules>
            <module>org.hibernate.eclipse</module>
            <module>org.hibernate.eclipse.console</module>
            ...
</modules>

 

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

<project ... >
<modelVersion>4.0.0</modelVersion> 
<parent>
    <groupId>org.jboss.tools.hibernatetools</groupId>
    <artifactId>plugins</artifactId>
    <version>3.4.0-SNAPSHOT</version>
</parent>
<groupId>org.jboss.tools.hibernatetools.plugins</groupId>
<artifactId>org.hibernate.eclipse</artifactId> 
<packaging>eclipse-plugin</packaging>

 

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

Conclusion

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

That is another thing I like about this setup

 

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

 

What do you think ?

 

Have you solved this problem differently/better/worse ?

JBoss Developer Studio 4.1, an update to the March 2011 release of JBoss Developer Studio 4, is now available for download!

 

  • If you're an existing Red Hat Support Portal user/customer, you can get access to JBoss Developer Studio via the Downloads section. But if you're a new user, all you need to do is signup to be granted access.
  • If you already have JBoss Developer Studio 4 installed, you can update your software using the update site through Eclipse.
  • You can get it for free (registration required) from http://devstudio.jboss.com/download/ (once that page gets refreshed)

What is JBoss Developer Studio 4.1?

JBoss Developer Studio 4.1 comes as a full easy to install Eclipse installation that bundles Eclipse WTP, TestNG, Spring IDE and the latest updated release of the supported plugins from JBoss Tools 3.2, including SOA-related tooling such as ESB, Drools, jBPM 3, and others.

Release highlights include:

 

  • Now based on Eclipse 3.6.2 (Helios SR2)
  • Includes bug fixes to many major components

BPEL Editor is Now Fully Supported

In JBoss Developer Studio 4.0, the BPEL Editor was included as a Technical Preview. The editor is now fully supported in JBoss Developer Studio 4.1.

JBoss Developer Studio Extras Site Includes More Certified 3rd Party Options

In JBoss Developer Studio 4, you had two certified 3rd party extras available for installation: Spring IDE and TestNG.

In 4.1, you now have the following certified 3rd party options:

 

  • eGit
  • FindBugs
  • Maven Integration
  • Mylyn
  • PMD
  • Spring IDE
  • Subclipse
  • and TestNG

 

To install these certified 3rd Party features from the update site, go to Help->Install New Software and select the "JBoss Developer Studio 4.0 Extras" site, which is predefined in the drop-down. Expand the "All Certified Features" item in the list and choose the features you want to install.

 

Have fun!


http://in.relation.to/service/File/10824

3.2.1

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

 

Earlier this week we pushed out an update of 3.2.1 to our updatesite. This release contains a bunch of bugfixes and one main component change that requires care when upgrading. Read below for details.

 

Remember JBoss Tools 3.2.x is for Eclipse 3.6/Helios, if you are on Eclipse 3.7/Indigo use JBoss Tools 3.3.* instead.

Installation/Upgrade

The component upgrade we've done is to move our JBoss Maven integration from m2eclipse 0.12 to support m2eclipse 1.0.0 since it is a massive speed improvement compared to previous releases of m2eclipse.

 

This unfortunately mean that if you used our JBoss Tools Maven integration you have to uninstall JBoss Tools Maven integration and m2eclipse 0.12 to be able to upgrade because m2eclipse changed bundle id's in their migration to Eclipse.org.

 

Same goes if you wish to install you need to be sure you do not have m2eclipse 0.12 installed.

 

You can uninstall Eclipse components in the "About Eclipse" and click "Installation Details" and uinstall all the "JBoss Tools Maven"  or "m2eclipse" components under "Installed Software" and click uninstall.

 

After this you should be able to update without any problems.

 

If everything fails a full installation would be the way forward. You can see the details for that at the JBoss Tools 3.2.0 release blog.

 

Have fun!

 

p.s. this is also my last blog before my vacation so be gentle and see you again in September

Koen Aers

Forge Commands on the Menu

Posted by Koen Aers Aug 5, 2011

These last weeks, we have been working hard to enable an exciting new feature of the Forge / JBoss Tools integration. The idea was to generate a popup with a list of plugins for which commands can be applied in the Forge console when a 'special shortcut' is pressed, much similar to the quick access feature in Eclipse.

 

To do this we needed to enable hidden communication of metadata from JBoss Tools to the Forge runtime and back. Today I am pleased to show the first results of this in the form of a first screenshot.

forge-ctrl-4-popup.pngAs you can see the popup contains a list of the Forge plugins for which there is a command applicable right after starting up Forge in JBoss Tools. The default way to bring up this popup is currently the key combination 'Cmd+4'.

 

Of course a lot of work still needs to be done for this to become really useful: all the applicable commands need to appear as children of the listed plugins and for these commands the different options need to appear somehow (probably as a new prepopulated popup). Afterwards the complete commands should be pasted into the Forge console view and executed.

 

Feedback and/or ideas are more than welcome!

 

Cheers,

Koen

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

We are looking for 2 core developers and a release engineer to work on JBoss Developer Studio product and the JBoss Tools project.

 

If you are into Eclipse development, want to work with some of the greatest talent in the industry and aren't afraid to get your hands dirty then take a look at the following positions recently posted on careers.redhat.com:

 

Core Developer - Webservices & SAP Integration

 

Core Developer - AS, OpenShift & Cloud

 

Release Engineer - Make it all work

 

p.s. no matter what the posting says these positions are available world wide in any country with a Red Hat presence.

 

If you want to hear more mail me at max.andersen at redhat.com or if you already are ready to go then apply directly on the above links.

 

Have fun!

/max

After a discussion with the SOA PMC it was decided that it would in the community's best interests to have the BPEL Designer project at Eclipse move to the SOA top-level project. This will promote the visibility of the project to a community that is more directly involved in the definition and use of business process design tools, thereby attracting developers with a vested interest in improving and maintaining the BPEL Designer code base.

 

The Restructuring Review documentation can be found here.

 

This move review is planned for July 7-13, 2011 and restructuring should be finished by end of July. Once this is done, the code will be merged with our  fork at JBoss.org and will become the official, fully supported BPEL tooling for JBoss Tools and JBoss Developer Studio. In doing this we hope to:

 

1. achieve better visibility in the open source community for the project and attract more contributors to help with bug fixes and enhancements

2. eliminate the need for keeping the JBoss.org and eclipse.org code lines in sync

 

Stay tuned for more updates...

http://community.jboss.org/servlet/JiveServlet/showImage/38-2030-10503/earlyaccess.pngThose interested in trying out our milestone builds of JBoss Developer Studio 5 can now do so from our Early Access Site.

 

JBoss Developer Studio 5 is the next version of our Eclipse based IDE targeted for development on JBoss supported platforms.

This version of Developer Studio is based on JBoss Tools 3.3. We've not included every plugin from JBoss Tools but the plugins we found ready to bundle into Developer Studio. As we go towards the final version we will evaluate which plugins will make it in based on our own QE and your feedback.

 

This milestone, we've focused on migrating to Eclipse 3.7, JBoss AS 7/EAP 6 support and separated out the SOA tooling so JBoss Developer Studio 5 will not include Teiid, jbpm, drools, ESB and Smooks by default - these are planned to be available from our Extra's updatesite going forward.

Installation

As last time there are two versions available, one with JBoss Enterprise Application Platform for developer use bundled and one without.

 

Please note that currently we bundle JBoss Enterprise Application Platform 5.1, but we will be moving to bundle JBoss  Enterprise Application Platform 6 when that becomes available.

 

The bundled version, requires registration via this form, but the unbundled version of JBoss Developer Studio 5 is available for free download.

 

Once you have downloaded the jar installer, you simply run it by double-clicking the jar (if your setup supports it) or run the following from the commandline:

 

java -jar <devstudio-installer-path>.jar

 

Then the installer will ask you a few basic questions and it will install JBoss Developer Studio 5 from which you will be able to start developing instantly.

Feedback

Instructions on how and where to give us private feedback for this early access is available here and otherwise we are listening in our public forums too

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 !

Filter Blog

By date:
By tag: