Max Rydahl Andersen is the tooling architect at JBoss by Red Hat.
In the early days he worked on Hibernate Core even before it became part of JBoss, and over time he have been involved in alot of projects at JBoss, mainly focused on the tooling/developer aspects.
He gets to touch upon almost every technology inside JBoss as they need tooling. It's given him a unique viewpoint of being an actual user of the technology - feeling both the pains and joys of a user.
Max have been involved in Ceylon from the early days and tried to keep up with the evolving specifications. Gives feedback and provide input in directions of the tooling and as such is now trying to make Ceylon available from Eclipse.
After an alpha, a beta, 2 CR's and countless nightly builds I'm proud to present the JBoss Tools 3 release!
Don't forget to read the installation instructions for JBoss Tools if this is the first time installing JBoss Tools (it is not so hard, you just need as a minimum Eclipse JEE bundle).
It is not recommended to update from Eclipse 3.3 to 3.4 via Eclipse updatesite - we recommend to do a fresh install.
Starting JBoss Tools 3 with a workspace created/used with JBoss Tools 2 is supported, but do take a backup just in case - let us know if you have issues upgrading.
You can see the improvements made since JBoss Tools 2 and up to this release here.
The major highlights since JBoss Tools 3 are:
- Seam pages.xml editor
- Improved code completion and better EL warnings
- Configure values for EL in Visual Editor
- Faster Visual Page Editor with updates for Richfaces 3.3
- Portlet Wizards
- Project Examples for easy access to sample projects
- Drools is back
- JBoss ESB projects and deployment
- JMX perspective
- Hibernate runtime support in Eclipse JPA projects
- Hibernate configuration can now use DTP and JPA configured connections
- Hibernate Birt integration
- ESB support in jBPM graphical editor
- TPTP profiling mode for JBoss servers
- Experimental Smooks editor
- Based on Eclipse 3.4 (Ganymede)
- ...and more
This is a major release and I dare not mention every individual that participated in this release from memory since I would most definitely forget some. Thus I'll list everyone who is listed in the commit logs in alphabetical order, without them nothing would have been done :
Alexey Kazakov, Aliaksey Nis, Anastasiya Bogachuk, Anton Klimkovich, Daniel Azarov, Dart Peng, Denis Golovin, Denis Maliarevich, Denny Xu, Dmitry Geraskov, Grid Qian, Igor Zhukov, John Graham, Koen Aers, Kris Verlaenen, Lex Dmitriev, Maksim Areshkau, Mikhail Sorokin, Nick Boldt, Olga Chikvina, Rob Stryker, Sean Flanigan, Sergey Dzmitrovich, Slava Kabanovich, Snjezana Peco, Svetlana Mukhina, Victor Rubezhny, Vitali Yemialyanchyk, Yagor Radtsevich, Yura Zhishko!
And to the top contributors in jira like Galder Zamarreño, Tom Feenelly, Krasimir Goutcev, Juergen Zimmermann, Francisco Jose Peredo Noguez, Adrian Mitev, Joao Paulo Viragine and everyone else who made contributions by emails, jiras and forum postings - Thank you! Without your feedback, our work would be boring; keep it coming!
One of the most wanted feature requests for our tooling is Maven integration/support for our projects, such as Seam.
Unfortunately we won't be able to add 'automatic' maven support in the upcoming JBoss Tools 3 release, but we have though started on doing the preparations to do so in a following release.
The biggest part of supporting Maven is that actual runtimes (i.e. Seam, Hibernate, the various specs involved etc.) is now fully
mavenized and the other part is that m2eclipse have matured greatly the last few months so it is now possible to combine Eclipse WTP projects with Maven without having your head explode too often.
To illustrate how well these things work together today without any additional features from JBoss Tools Snjezana Peco made a few screencasts of how to use the examples she made available through JBoss Tools 'Project Example' functionality which are Seam projects that work with the Maven support m2eclipse offers.
- Eclipse 3.4 with JBoss Tools 3 or Developer Studio 2 (CR2 or latest release works with this)
- JBoss AS 4.2, EAP 4.3 or AS 5 GA (the example work with either)
- Seam 2.1.1 GA
- A recent m2eclipse, from Sonatype's updatesite
The following two screencasts Snjezana recorded shows how it works:
Screencast #1: Installing m2eclipse and get the Seam/Maven project example
- Snjezana starts of with showing JBoss Developer Studio 2 (you can use JBoss Tools too, just requires a bit more typing/manual configuration)
- Shows where Seam and AS is configured
- Goes to Help > Software Updates to install m2eclipse from their update site
- Selects Maven Integration, Doxia editor and Maven Integration for WTP under Maven Project Configurators (you can choose them all, but these are just the important ones)
- Wait's for the download and the install etc.
- When m2eclipse is installed she goes to
Project Examples, types in
mavenand selects the
Seam Booking Example - EAR mavenized - seam 2.1.21.GA
- Wait for the download and Maven getting all its dependencies
- Uses quick fix to configure the proper runtimes (i.e. jboss-seam-2.1.1.GA and JBoss 5.0 Runtime), if you had those configured from the start this step would not be needed.
- Wait for the project to compile
Screencast #2: Using the Project Example and how to deploy/use the application.
- Shows again how to get the Seam booking example via
- Show's that the project is really a Maven project and have all the Maven features enabled
- Find and marks the datasource file (-ds.xml) as Deployable so the datasource will be known to JBoss
- Add the project to server which will deploy it
- Starts the server and goes to http://localhost:8080/booking/home.seam and see the Seam project runs
There you have it - nothing more to it. A mavenized Seam project where all the features of JBoss Tools is available next to all the Maven features m2eclipse brings to the plate.
Snjezana manually adjusted the pom.xml and Seam settings in tools to get this, in upcoming versions of JBoss Tools we will make sure that you can enable this automatically on new Maven/Seam projects.
Hope you like it!
Have fun! /max
Remember the blog, How to create a visual DocBook editor in 10 minutes and how it described how to create a Docbook editor with the Visual page editor in JBoss Tools ?
It turns out Ronald van Kuijk picked it up and created a visual editor for XForms. He introduced his attempt on our forums yesterday, and in the evening he was fully running and did a blog showing of the features including screenshots.
Here are two of them (click for full size):
XForms as it looks by default without the plugin:
XForms as it looks with the plugin enabled:
You can download the experimental plugin here.
Since Ronald were so much on fire I instantly offered him to host the sourcecode for him at JBoss tools SVN .
That is what I like about open development, from idea to execution within less than 24-hours.
EclipseCon 2009 is getting closer and I really should get started preparing my talks.
While trying to start working on the talk I saw the following list dropping into my inbox with curtesy of Nick Boldt. It is the list of talks where one from JBoss or Red Hat is involved (if we missed one let us know).
Hands-On: Using the new Common Builder for Push-Button PDE Builds a 4-hour tutorial by Nick Boldt, Andrew Overholt, Andrew Niefer (IBM)
Executing BPMN by Koen Aers a long talk by Koen Aers.
Hands on with JBoss Developer Studio a 2-hour tutorial by Jim Tyrrell and Max Rydahl Andersen
New opportunities for server adapter providers in the new Server View, a 10 min. short talk by Rob Stryker
An update on the Linux Distros/Tools project, short 25 min talk by Andrew Overholt
Max and John's Excellent Plug-in Adventure: The Highlight Reel by John Graham and Max Rydahl Andersen
BoF: Linux Extended IDE - Linux Tracing a BOF by Andrew Overholt et.al.
JBoss is sponsoring a 10% discount for attendees to EclipseCon, you can use the coupon code JBOSS10 to get it!
See you there!
Now these links have been fixed and to recap here is the way to get JBoss Tools:
...and if in doubt read our Installing JBoss Tools wiki page.
And just as a final note:
To err is human, to forgive divine
I just got the word that JBoss Developer Studio 2 CR2 is now available for download for free from the beta download page or via the Customer Support Portal (CSP) (requires a subscription).
This version incorporates the productized plugins from JBoss Tools 3 CR2 plus updates to the bundled 3rd party plugins and platforms.
JBoss Developer Studio contains most parts of JBoss Tools but to illustrate what is included in JBoss Developer Studio from JBoss Tools and what is additionally provided you can go read the "Developer Studio vs. JBoss Tools" which illustrates exactly this.
From this release and going forward we we now are offering two different bundles, one with JBoss Enterprise Application Platform (EAP) at about 600 MB and a bundle that does not include EAP at about 300 MB. That gives users that already have one of our platforms installed to download the much smaller bundle.
The installer have also been made intelligent enough to allow you to get your existing runtimes (EAP, SOA-P, JBoss AS etc.) automatically configured as long as you tell the installer where it should find the runtimes.
Many things in Eclipse require or uses a classpath, i.e. java projects, junit and server launches, hibernate console etc. For these classpath containers are handy to use instead of forcing users to individually pick the (possible long) list of jars needed to get their work done. A classpath container allow plugin providers to automatically create a group of jar's which can be added and removed in one operation - simple and efficient.
Unfortunately I've seen over the years that many plug-in's create what I call navel-gazing classpath containers which creates a bigger problem than it solves.
Let's take the latest example from JBoss Developer Studio we had to fix, the Drools plugin classpath container:
This screenshot shows the default classpath container provided by earlier versions of Drools plugins. Notice how all the jar's points to a fixed internal location (.cp\lib) inside the Drools plugin, that is what I call a navel-gazing class path container.
First, lets see why so many plugins seem to do it this way. There is (only) one
good reason for having navel-gazing classpath containers.
That is to reduces the setup time since no separate configuration is needed to define where the runtime/set-of-jars are located.
With a navel-gazing class path container the Drools plugin can out-of-the-box provide a running
Drools project without any knowledge and any influence by other plugins/projects. That is a good thing, right ? Well...
Why do I not like this navel-gazing ? Don't I want users to get started as easily as possible without having to think about details like which dependencies the project has ?
Sure, I want users to get started as easily as possibly with their work but any developer should actually care about or at least have some awareness about which dependencies a project have - and if we use navel-gazing classpath containers they don't have to be aware.
Furthermore when it come to newbies it is my experience that they have a tendency to think that projects created by wizards in their IDE's is the best way of creating projects - if the IDE does it, then it must be correct and should not be questioned.
Therefore it is important that the project your plug-in creates is actually something that is useful when a project evolves over time, updates it dependencies and possibly gets developed together with a team. (that is at least the goal for a good IDE)
Unfortunately navel-gazing classpath providers is doing the exact opposite.
It is not something you should use on a team because all the jars point to jars inside the plugin and thus it is most likely dependent on which version of the plugin the user is running. If a team does not keep the versions of plugin in sync the team risc to be running against different jars resulting in possible compile errors and in worst case subtle runtime differences.
Another common issue with navel-gazing classpath containers is that they only support one possible runtime. Making it impossible to have projects in your workspace that uses different version of the jars, i.e. having a old version of your project using Drools 4 with Java 5 and a new version of your project Drools 5 using Java 6 would require multiple Eclipse installations.
Imagine if Eclipse only supported projects that worked with the Java version you were running Eclipse it self with ? Not very useful.
Even worse is that if a user updates his plug-in via an updatesite he will (probably unwillingly) change the runtime dependencies of his projects because the jar's inside the plug-in are now updated.
Another example of a navel-gazing classpath container is the Ant or JUnit classpath container provided by eclipse. These also links to classpath's inside Eclipse causing the same kind of issues as described above. Though since Ant and JUnit are very stable and mature frameworks it is not so bad but in principle it is wrong and your projects should not use these classpath containers lightly.
Ok, so navel-gazing is bad; what should plug-ins do instead ?
Let's look at a good classpath container everyone should know: JRE classpath container provided by Eclipse Java Development Tooling (JDT).
The screenshot shows what the classpath container provides when you
have created a Java Project. Notice how the jars are from some external location.
These locations are defined in preferences under
These locations all have names allowing a team to just sync up which names (which actually are id's) to use for it's dependencies, it also allow to use multiple runtimes within the same Eclipse instance and it points to a well defined location which is under the user control i.e. not dependent on any updates to your eclipse plugins.
This simple notion of having explicit defined locations for your runtimes makes a big difference and this is what any decent plugin should do if it wishes to provide a framework specific classpath container.
And that is also what the Drools team did in the end and the result is a non-navel-gazing classpath container:
Of course there are other solutions to this problem, namely not to use plugin provided runtimes provided by plugins at all and instead use something like Ivy and Maven for full dependency management.
If you want to use full dependency management inside Eclipse take a look at m2eclipse which actually provides a classpath container which jars are calculated based on your Maven dependencies. There is also IvyIDE that does the same for Ivy.
John Graham and I are doing a talk at EclipseCon 2009 called "Max and John's excellent plugin adventure - The Highlight Reel" where we will present and discuss anti-patterns like the above.
Do you have any favorite Eclipse anti-patterns ?
JBoss Tools 3 CR2 is ready! The next one will be GA.
160+ issues have been fixed since CR1 based on the feedback we have received (Thank You!)
We are heading for GA and therefore not a lot of new features, except for a few which you can see in the New and Noteworthy.
I especially like the code folding in Visual Page editor for XML/HTML including namespaced tags like
While you download the new release you can go and look at some of our recent entries for JBoss Tools:
- The FreeTee project, where Galder shows how he uses project archives from JBoss Tools to have quick incremental build of rt.jar from OpenJDK
- The JBoss Tools Code swarm done by Emanuel
- The Logo Jira where you can contribute ideas to the work for a JBoss Tools logo (the final one will be chosen for the GA)
As always feedback is very much appreciated.
Galder got a blog entry describing how to use Project Archives available in JBoss Developer Studio and JBoss Tools to build the rt.jar in OpenJDK.
The initial build is of course lengthy but any following changes done gets instantly updated into your rt.jar allowing you to have very fast turnarounds when trying out your own JDK experiments.
Emanuel Muckenhuber send me this video today showing how JBoss Tools trunk looks like when animated with code swarm.
The period is from December 2004 to January 2009. In the beginning all is pretty quiet/simple when JBoss Tools just contained Hibernate Tools, AS tooling and Project archives - but wait and see what happens around May 2007 and forward when we announced JBoss Developer Studio and got contributions from Exadel; pure fireworks:
You can see the full video here.
p.s. this is just JBoss Tools trunk which does not contain jbpm and drools hence you won't see activity for them.