Wednesday, September 26, 2007

Glassfish v3 and JavaEE 6

More than likely most haven't gotten the chance to use JavaEE 5.0 yet, but I think it's important to look ahead at what is coming down the road. I believe, container-wise, JavaEE 6 is going down an excellent path of easier development by making their container as small as possible (15k) and startup time super fast (less than 2 seconds). How did they achieve that? Modularity.

For some reason I just realized that the Reference Implementation (RI) for JavaEE 6.0 is Glassfish v3. Skim this presentation about the goals of JavaEE 6.0 (roughly about 15 quick slides). Also, here is a walk-through on how to use Glassfish v3 (install jruby container, web container, etc).

Just for the record, also keep in mind that JavaEE 5.0 is implemented by Glassfish v2.

Saturday, September 22, 2007

How to effectively use SNAPSHOT

Recently I showed how you can use the maven-release-plugin to create a release for your project. Now I would like to explain how to use maven to effectively use SNAPSHOT.

First what do I mean by SNAPSHOT? SNAPSHOT is a special version in maven that indicates the latest code; typically TRUNK or HEAD in your source control. With this version, maven will automatically grab the latest SNAPSHOT every time you build. On the other hand, when you are using 2.0, once maven has downloaded this artifact, it never tries to get a new 2.0.

Why should you use SNAPSHOT? You should use SNAPSHOT for rapidly moving code where bug fixes and enhancements are coming fast. Another reason is you should never require users of your project to checkout and build your code. EVER! I would venture to say that 50% of the open source projects I have had to checkout and build, have not initially built.

How to create a SNAPSHOT?
First you have to find a webserver to host the artifacts. I have typically used apache running on linux. I first create a folder under / called snapshots (owner:group equal to repoman:repoman) and then create a softlink (ln -s) under /var/www/html called snapshots (owner:group being root:root). So now you should have /var/www/html/snapshots --> /snapshots. For some examples of some public SNAPSHOT repositories check out Apache's and Codehaus.

Second you need to update your parent POM in order to properly use the maven-deploy-plugin. First make sure the version you are using includes -SNAPSHOT. For example something like 0.9.2-SNAPSHOT.

Third add the distributionManagement section to your parent POM to look something like this:

<name>Maven2 Snapshot Repository</name>
This will use scp to upload the artifacts to the url //host/snapshots. The element that needs to receive the most of your attention is <uniqueVersion>. This value can either be true or false. When it is false the artifacts created will not be unique and will look something like this each time: myproject-0.9.2-SNAPSHOT. Use this to reduce disk usage. When it is set to true a unique version is created everytime. For example myproject-0.9.2-20070922.011633-1.jar and then the next build that day would be myproject-0.9.2-20070922.011633-2.jar.

Finally, the last thing is to set the username and password of the repository in your $USER_HOME/.m2/settings.xml file. This will be used by scp for authentication. To do this add the following in your settings.xml file:
That is it. Now you are ready to run mvn deploy.

Wednesday, September 19, 2007

JBI Deployment Options

Recently, I have had multiple discussions with different individuals concerning possible JBI deployment options for their projects. Is Glassfish required? Do I need a JavaEE container? Do I need Netbeans? Is it packaged as a WAR? How big is the runtime footprint? If I am already using JBoss, how can I take advantage of JBI? Why is the OpenESB installer so large? Even with every project having its own specific needs, JBI has an array of potential solutions for each one. So if you are new to JBI or just curious how to use it, please contiue to read while I describe the various options.

First, I have fortunately had the pleasure of extensively using two of the most popular JBI containers currently available: Apache ServiceMix and Sun's OpenESB. The following is the landscape as I see it based off my experience.

Apache ServiceMix Options

  • Can run as a standard J2SE application. To use this version download the container from here:
  • Bundled as a WAR, making it deployable to your existing JavaEE container. The WAR is also available for download from the same address above.
Sun's OpenESB Options
  • Can run as a standard J2SE application. Although it's a little more untested than it's other options. Go here for a How-To Guide on where to download the container and run it.
  • Comes bundled in an All-In-One install that includes the latest Glassfish, OpenESB, and Netbeans 6.0 for tooling support. Go here to download this version. Before you flip out on the download size (300+MB), let me provide an explanation as to the size because this seems to be the version receiving the most attention by Sun; and it's actually the version my team uses. Along with the items mentioned above, this bundle also includes all the Sun components and the latest Community Partner components. I believe the main benefit to having an All-In-One install is previously we had to download each project individually and usually the different versions where incompatible (the BPEL tooling support in Netbeans didn't match the BPEL Service Engine capabilities downloaded with OpenESB). It's important to note that with this option Netbeans is only required to compose Composite Applications and not to run OpenESB. Finally, the Glassfish and OpenESB combo is a little deceiving in that it's not like starting two applications. OpenESB is basically exploded out in one of the Glassfish domains, much like a WAR would be. So when you start a Glassfish domain, it handles starting OpenESB.
  • There exists a WAR file for IBM Websphere located here and work has been done to integrate with JBoss (read here for more information).
Which one is right for you?

Most projects fall into two categories: one that already has a JavaEE container and ones that don't. If you already have a JavaEE container, then you can use the ServiceMix WAR or run the J2SE standalone version of OpenESB. If you don't have one, then obviously you can choose among all the options. If I was forced to give a personal recommendation, I would recommend when possible using the Glassfish/OpenESB package. This gives you complete capability of building Composite Applications consisting of Web Services running in Glassfish and orchestrating them using OpenESB and the BPEL Service Engine and then integrating with other protocols such as RSS, SIP, UDDI, and XMPP. And the tooling support in Netbeans is well worth it.

For further questions please visit the FAQ on or feel free to drop me a comment. You can also subscribe to my shared JBI RSS Feed.

Friday, September 14, 2007

How to create a release using the maven2 release plugin

If you haven't figured out how to simplify creating a release for your maven2 projects then you need to look into the maven-release-plugin. This powerful plugin helps shorten the time it takes when creating a release and we have used it extensively on our open source projects: RSS BC, SIP BC, UDDI BC, and the XMPP BC.

Kicking It Old School
Back when we were using maven1 we actually used a sed script to update the versions in the project.xml and files. Boy those where the days; how I don't miss them. However, I was still impressed with it so here you go. Create a script named swap:
cp $1 $1.backup
sed -e s/"$2"/"#3"/g $1 > temp
cat temp $1

Browse to your project and run:
find -name '' -exec ~/swap {} 1.1.0-SNAPSHOT 1.1.0 \;
find -name 'project.xml' -exec ~/swap {} 1.1.0-SNAPSHOT 1.1.0 \;

It was effective and did the job (in fact it's easier to use a perl script), but you still had to create the tag/branch and commit. Also with maven2 POMs you have other values that have to be updated like the <scm> information.

How to use the maven-release-plugin
First, you need to clean up your POMs. Here are three basic guidelines that will make your life easier when managing them:

  1. Avoid declaring groupIds and versions where it is not required. For example in child POMs, if the groupId and version are the same as the parent, you don't have to define your own groupId or version. By default it inherits from the parent.
  2. If you do have to declare versions, use the section of your parent POM. This helps define your downstream dependencies and prevents the child POMs from having to declare the versions that are shared among the project.
  3. Use properties to define other common versions.
For a real example, view the RSS BCs parent pom, and subsequent child poms: extensions, jar, and zip. Notice the use of properties and dependencyManagement in the super pom. Also note how the child POMs don't have to declare versions for inner project dependencies that are defined in the parent POM under dependencyManagement.

Now that you have your POMs cleaned up it's time to use the maven-release-plugin. It doesn't actually require these changes, but I am anal so sorry.

Make sure your parent POM has the <scm> section describing the projects source control location.

Get a clean copy of your project. The maven-release-plugin will not run if you have locally modified files; including IDE files or the target folder.

Run mvn release:prepare -DdryRun=true
This will walk you through a dry run and you can view the temporary POMs it creates to verify you did everything correctly.

Run mvn release:clean release:prepare -Dusername=johndoe -Dpassword=passwd
This will actually commit a tag with non-snapshot versions of your project and also increment all your versions to the next release. So for example, if your current version is 0.9.1-SNAPSHOT, it will commit a tag with 0.9.1 version, and update the trunk POMs with 0.9.2-SNAPSHOT. Of course when using the prepare goal you are prompted for the release numbers and next release numbers.

Run mvn release:perform
The perform goal basically runs deploy and site-deploy. This step is optional and I typically don't run it.

One gotcha is if your project has a SNAPSHOT dependency on an artifact outside your project, the release plugin doesn't handle that (or at least I haven't figured it out). The prompts seem to ask questions about what version they need to be, but never actually does anything with the information. Hopefully this will be fixed in future versions. In the mean time, use properties, and when running mvn release:prepare use the -D option to specify the version and then manually update the tag and trunk pom to reflect the real version. So something like mvn release:prepare -DdryRun=true -Dcommon.jbi.runtime.version=0.9.2.

Windows Users
The other issue you might have is if you are using Windows. Since I am using Linux the svn commands are already installed and I use them frequently. And since the release plugin uses the svn commands to do its work, you will need to install the svn client commands in order to it in DOS. To do that go here, go down to the Windows section, and click Win32 packages built against Apache 2.2. In there download and install the svn-1.4.6-setup.exe. After installing it, open up a new DOS window and run svn help.

For further tips and tricks read the Gestalt Developers Guidelines for creating a release using the maven-release-plugin.

Related Articles