The Early Access site for JBoss Developer Studio now contains CR1 free for download and if you want the JBoss Enterprise Application platform bundled you just need to and sign up for the early access program here.
This release contains a few improvements over the last couple of betas that are worth mentioning.
Most of these stems from the change we made from using the horrible dropin feature of Eclipse to have a proper
P2 enabled Eclipse product build. This should make things like installation, startup and updates much smoother, simpler and in some cases faster.
There is no longer a seperate "eclipse" directory; everything related to JBoss Developer Studio is now in the "studio" folder and
instead of using raw eclipse to start you now uses the jbdevstudio, jbdevstudio.exe or the JBoss Developer Studio.app dependent on your
platform to launch.
If you have installed the EAP bundle jboss-eap still lives in <install>/jboss-eap.
You can still use the "Server" page in the installer to setup JBoss server runtimes, but all this that was previously isolated in the installer is now also available from inside JBoss Tools under the Preferences for "JBoss Tools Runtime Detection". Here you can configure directories to scan for runtimes and it supports not only Server runtimes, but also standalone framework runtimes like Seam and Drools.
You will also now be greeted with a new shiny Welcome Screen:
...and of course the latest stable fixes and features from JBoss Tools 3.2.
The very first version of Context Dependency Injection (CDI) Tools was introduced as a part of JBoss Tools 3.1.0. But now JBoss Tools 3.2 is moving to its first stable release. Let's have some review of main features of the improved and up coming CDI Tools in JBoss Tools 3.2.
First at all we need to enable CDI support for the project. If you already have some CDI project and don't want to start from scratch then just go toProject Properties->CDI->CDI support to enable all the features.
If your project is Maven-based and the pom.xml references the CDI api jars CDI support will be enabled automatically. If you want to create a brand new WTP project with CDI support, just add a CDI facet to the list of installing facets.
See Max's blog Simple CDI Hello World with Eclipse and JBoss Tools for details.
Make sure you have CDI support enabled for all the related projects. For instance if you have a web project (is to deployed as WAR) which uses some Java project (JAR) then both projects should have CDI support enabled.
If you are interested in Weld examples (Weld is the reference implementation of CDI spec.) you can download it from JBoss Tools example site.Help->Project Examples->Weld 1.0.1
There are a set of CDI Wizards to help you to create basic CDI artifacts. The wizards are available in File->New->Other...->CDI
CDI validation covers most of the rules declared in the JSR-299 specification. There are 100+ validation rules including definition errors and deployment problems. You can see the full list in the CDI Preferences, where you can also control which rules you want to be Errors, Warnings or simply Ignored.
The CDI validator checks for problems in java source files, JSP, XHTML and beans.xml files.
Some of the validation problems can be fixed via Quick Fixes menu (Ctrl+1):
Another useful feature is a code completion. CDI tools provides two types of code completion. Code completion for @Named beans and their members which are available in EL expressions:
And code completion for the relevant types/annotations in beans.xml:
Hyperlinks help you to navigate between source files. For example Ctrl+Click or F3 on any EL will navigate you to the corresponding java source.
For Injection's it is a bit more tricky. The built-in Java hyperlink for its declared type will open the type. But for Injection there are additional relevant items to navigate to. CDI Tools offers you an alternative navigation to the actual bean which is to be injected.
If the injection has multiple eligible beans, you can see a full list of these beans. Btw. you can fix the multiple eligible beans via a quick-fix (Ctrl+1).
Also you can open the corresponding class/interface mentioned in beans.xml via the same Ctrl+Click on the type name.
Observers and Events can be navigated to via OpenOn too.
As well as Producer and Disposer methods:
At last we also have:
This was a quick overview of the main features of up coming JBoss Tools 3.2 for CDI developers.
If you think CDI Tools misses some useful functionality then please create a feature request in JIRA! We are working to help you to enjoy this exciting world of CDI
If you are familiar with the Eclipse platform the installation should be a breeze for you. The easiest way is to download a recent Eclipse version and use the 'Help->Install New Software...' wizard to install the latest and greatest JBoss Tools from the update site. Don't forget to include the Maven integration for Eclipse as we will need it later on. After this, use the same mechanism to install the forge tools from this update archive. Restart Eclipse and you should be set to go.
Now that the installation is dealt with, let's have a look whether everything went ok. You can bring up the "Forge Console View" by selecting 'Window->Show View->Other...' and then 'Seam Forge->Forge Console'.
As you can see the Forge Console View has a toolbar and a dropdown menu that allow you to start and stop Forge. The initial message pane indicates that Forge is not running. Let's get going and push the 'Start Forge' button.
After a while, the Forge welcome banner appears and you are invited to enter forge commands. The very convenient tab completion suggesting the list or possible commands does not work yet, but you can get the suggestions anyway by pressing tab followed by a return. Also, the coloring is not yet enabled like when using Forge directly in a terminal window. When you're done working you can stop Forge by pushing the 'Stop Forge' button.
To make things a bit more interesting, let's try the tutorial from Lincoln's blog. We create a new project called 'foo' with top level package 'org.foo':
[no project] workspace $ new-project --named foo --topLevelPackage org.foo
Now the project is created but unfortunately, we cannot see it in our workspace. This is one of the obvious features that need to be added. For now, we have to import the project in the workspace. Here is where the Maven plugins come into play. For Forge projects are indeed Maven projects too. Select 'File->Import...' and then 'Maven->Existing Maven Project'. Point the wizard at the workspace root and the 'foo' project should show up in the list of projects to import. After importing the project shows up in the package explorer.
[foo] foo $ install forge.scaffold
[foo] foo $ new-entity --named Person
[foo] Person.java $ new-field string --fieldName firstName
[foo] Person.java $ new-field string --fieldName lastName
[foo] Person.java $ cd ..
[foo] domain $ scaffold generate-metawidget-jsf *.java
To see which changes are performed in the project by these commands we need to refresh the project.
Again, it would be good if after issuing each command the relevant changes would be highlighted by setting the relevant folder, file or file element selected. This is more work for the future.
As suggested, a lot more work is waiting... Some of the features that are on the list are:
If you are interested in helping out implementing some of these features or if you just want to view the code implementing the current console, you can find the sources in the JBoss Tools SVN.
Note: Downloads are now being served from download.jboss.org while we wait for Sourceforge getting their issue fixed.
What's New covers the usability fixes there have been added, and a few new additions/improvements.
Even though we haven't been on Eclipse Marketplace for long we are already the 6th most downloaded Eclipse plugin within 30 days on Eclipse Marketplace; and in 9th place of all time.
Thank you for the interest and usage - if you don't know Eclipse Marketplace, you can see how to use it here.
For those already using it, I encourage you to go and give us your star or even a review at our Eclipse Market Place page
First of all this release finally enables one of my favorite new features "Automatic Runtime Detection". It's been possible for a while now to use the "Search" button under JBoss Tools to find JBoss runtimes and have them configured and setup in the IDE for direct usage without having to set up all the individual parts.
In this release we have gone a bit further and allowed you to configure a set (one or many) of directories that JBoss Tools will scan on new workspaces or if you enable it at every startup; if anything new is found it will show the new items and you can then say if you want the runtimes to be installed or not.
This means when you install a new version of JBoss AS, Seam, Drools, EAP, SOA-P, etc. you can simply put in this "watched" directory and JBoss Tools will configure them for you in the IDE. In the future we will add more types of runtime distribution detection such as Java JDK's.
This feature is available under Eclipse Preferences in JBoss Tools > JBoss Tools Runtime Detection
For Context Dependency Injection (CDI) we've added a few quick fixes against some of the more common issues our validator finds.
This allows you to use Ctrl+1 on warnings and fix issues. For example fixing @Produces annotations on non-static methods in a Session Bean by making the method static.
We've also added support for the Maven integration to enable CDI automatically if/when your pom.xml file referenes the CDI api jars. Making it simple to import a Maven based CDI project and have all features enabled.
There is more shown in What's New, take a look, try the release and let us know how it goes! If nothing major is found we'll be releasing the final version within the next couple of weeks.
Let's face it,BPEL has become the de facto standard for building industrial strength business work flows, despite the fact that it is not for the faint of heart and, much like suicide by lapidation, it requires a strong will and determination to get through the pain.
Red Hat/JBoss recognized the importance of BPEL in the enterprise quite a while ago and as a result, a WS-BPEL 2.0 compliant engine and tooling is being offered as a “Technical Preview” in SOA-P 5.1, which is due to release sometime this spring.
Technical Preview simply means that it will be bundled with SOA-P but it will not be officially supported until the 5.2 release scheduled for this summer. However, we the developers will still do our best to respond to feature and bug fix requests from the community, as always.
Riftsaw, which is the BPEL engine that ships with the above mentioned products, is based on Apache ODE version 1.3.4 and in fact, JBoss developers have been very active in the ODE community and have been instrumental in determining the future direction of the project.
The Riftsaw engine is optimized for the JBoss Application Server and supports a variety of features which you can read about in the project pages here.
Startup and shutdown of Riftsaw and deployment of business processes to the engine, as well as control of process instances can be done either through the Eclipse tooling, or using the BPEL Console shown below. Before you start, make sure that your JBoss Application Server environment is installed and configured correctly and you have installed Riftsaw as described in the User Guide.
The “Servers”view is used to manage the Riftsaw engine from the Eclipse tooling, as shown here:
To create a new server instance in Eclipse, simply select “New” from the Servers View context menu (right-click) and follow the wizard; first select the JBoss App Server version. Currently this must be 5.1.0.GA - support for AS 6.0 is being considered for a future release.
Next, select the AS installation directory:
and finally, deploy your processes - that's all there's to it!
Over a year ago, JBoss made the very difficult decision to fork the Eclipse BPEL Designer source because apparently the original development team was unable to commit the time and resources to maintain the editor, for whatever reasons and the project has been floundering until recently. Since then a lot of improvements and bug fixes have been made and the BPEL editor is finally stable enough to be considered a beta release! Not only are there other Eclipse projects that depend on, and use the BPEL Designer, but it has been officially integrated into our QA cycle.
In the coming months these fixes and enhancements will be pushed back upstream to the Eclipse code line and made available to the community. The plan is to rekindle community interest in this project and eventually have it be self-sustaining so that we can finallyretire our forked code line. The fact that we have been able to gain some measure of control over the code at eclipse.org will make this task much simpler.
We still have some features we'd like to see implemented in the editor and runtime, such as:
The current graphical UI has long been criticized for being less than user friendly and several ideas have been tossed around which would improve the user experience. We hope to implement each of these as time permits.
The reason for offering BPEL as a Technical Preview is so that early adopters can get their hands on new technology goodies to start playing with them and provide us with valuable feedback! This will help us shake out bugs and help us offer a better product. But this only works if you, the users, provide us with that feedback.
So if you are an early adopter and run across a bug, or you see a need for a new feature/enhancement, please let us know by posting to the JBoss or Riftsaw community user forums. For BPEL Designer-specific issues and questions, you can also post directly to the Eclipse BPEL project forum.