Maven Plugins: Upgrade with Care!

Upgrading Maven Plugins: Tips and Issues

After having shown the list of current Maven plugin versions in my previous post, now I'm going to share my experiences with upgrading. Just like expected, some of the new plugins did not work out of the box or required some changes in configuration:

maven-checkstyle-plugin

We have used version 2.3 previously which is based on Checkstyle 4.4. In contrast, plugin version 2.4 is eventually built on top of Checkstyle 5 which better supports Java 5 language features (I wrote a post on that issue). The configuration is not fully compatible, so you would have to upgrade it.

maven-javadoc-plugin

Starting with version 2.6, JavaDoc plugin can detect the Java API link for the current build. This did not work for us (probably due to missing proxy configuration), so we had to switch it off by setting detectJavaApiLink property to false. See plugin site.

taglist-maven-plugin

The configuration of tags has changed and is now a bit more extensive. Old format (using tags element) is still supported, but deprecated. See plugin documentation.

findbugs-maven-plugin

I have used version 2.2 which was the most recent one when changing the POM. However, this yielded some strange errors during site generation. This is the strack trace:

Generating "FindBugs Report" report.
  Plugin Artifacts to be added ->...
  AuxClasspath is ->D:\Profiles\Default User\.m2\repository\org\apache\maven\reporting\maven-reporting-impl\2.0\maven-reporting-impl-2.0.jar;...
[java] Exception in thread "main" java.io.FileNotFoundException: D:\builds\...\User\.m2\repository\...\maven-reporting-impl-2.0.jar;D:\Profiles\Default (The filename, directory name, or volume label syntax is incorrect)
[java]  at java.util.zip.ZipFile.open(Native Method)
[java]  at java.util.zip.ZipFile.<init>(ZipFile.java:114)
[java]  at java.util.zip.ZipFile.<init>(ZipFile.java:131)
[java]  at edu.umd.cs.findbugs.classfile.impl.ZipFileCodeBase.<init>(ZipFileCodeBase.java:53)
[java]  at edu.umd.cs.findbugs.classfile.impl.ZipCodeBaseFactory.countUsingZipFile(ZipCodeBaseFactory.java:92)
[java]  at edu.umd.cs.findbugs.classfile.impl.ZipCodeBaseFactory.makeZipCodeBase(ZipCodeBaseFactory.java:46)
[java]  at edu.umd.cs.findbugs.classfile.impl.ClassFactory.createFilesystemCodeBase(ClassFactory.java:97)
[java]  at edu.umd.cs.findbugs.classfile.impl.FilesystemCodeBaseLocator.openCodeBase(FilesystemCodeBaseLocator.java:75)
[java]  at edu.umd.cs.findbugs.classfile.impl.ClassPathBuilder.processWorkList(ClassPathBuilder.java:564)
[java]  at edu.umd.cs.findbugs.classfile.impl.ClassPathBuilder.build(ClassPathBuilder.java:195)
[java]  at edu.umd.cs.findbugs.FindBugs2.buildClassPath(FindBugs2.java:584)
[java]  at edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:181)
[java]  at edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:348)
[java]  at edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1057)
[java] Java Result: 1

As you can see, we are using Windows default for local Maven repository (D:\Profiles\Default User\.m2) which obviously is causing a problem with the path later on. How sick is that?!?

Then, after having tried this and that, I discovered there is a brand new version 2.3 available so I tested that one and guess what – everything works fine again! Hence, don't use version 2.2, it seems to be broken...

docbkx-maven-plugin

The latest version of that plugin is 2.0.9, but that did not work correctly. It failed the build with this error:

ValidationException: null:30:723: Error(30/723): fo:table-body is missing child elements.
Required Content Model: marker* (table-row+|table-cell+)

The given line/position information did not match to anything suspicious, and I could not see anything wrong in our XSL files. So, no idea what this issue is telling me or what could I do about it. That's why I rolled back to 2.0.8 which just works fine.

The Bottom Line

With the given plugin versions, we are up to date again and managed to get rid of some issues hitting us since quite some time. Additionally, we are well prepared for upgrading to Maven 3. I hope I will be able to do so soon, to check if this is really a "drop-in replacement"... I will let you know!

Read More

Maven Plugins: Current Versions

Upgrading Maven Plugins

In preparation for a later switch to Maven 3 (which is already knocking on the door) as well as to get rid of some plugin related issues we are suffering from, I decided to update the Maven plugins we use for build and site generation.

Of course, we are following best practice and are locking down the version of all plugins in project.build.pluginManagment.plugins section. This is done in the company's topmost POM, so that all company projects would use the same versions once they reference the latest parent POM.

As you might know, upgrading to new plugin versions is always an adventure and you have to test your builds seriously, which is of course hard when you are going to change the company settings...

Build Plugins

Well, here is the list of build plugins we now use with their current version, as well as (in brackets) the version that Maven 3.0-alpha5 defines in its internal POM. I have highlighted where both versions differ:

• maven-archetype-plugin: 2.0-alpha-5 (see comment below)
• maven-assembly-plugin: 2.2-beta-4 (2.2-beta-4)
• maven-clean-plugin: 2.3 (2.3)
• maven-compiler-plugin: 2.0.2 (2.0.2)
• maven-dependency-plugin: 2.1 (2.0)
• maven-deploy-plugin: 2.4 (2.4)
• maven-ear-plugin: 2.4 (2.3.1)
• maven-ejb-plugin: 2.2 (2.1)
• maven-enforcer-plugin: 1.0-beta-1
• maven-help-plugin: 2.1 (2.1)
• maven-install-plugin: 2.3 (2.3)
• maven-javadoc-plugin: 2.6.1 (2.5)
• maven-jar-plugin: 2.3 (2.2)
• maven-release-plugin: 2.0-beta-9 (2.0-beta-9)
• maven-resources-plugin: 2.4.1 (2.4.1)
• maven-site-plugin: 2.0.1 (2.0.1)
• maven-source-plugin: 2.1.1 (2.0.4)
• maven-surefire-plugin: 2.4.3 (2.4.3)
• maven-war-plugin: 2.1-beta-1 (2.1-alpha-1)
• build-helper-maven-plugin: 1.4
• failsafe-maven-plugin: 2.4.3-alpha-1
• cargo-maven2-plugin: 1.0
• docbkx-maven-plugin: 2.0.8

It's a bit strange that Maven 3.0-alpha5 (which came out end of November) does not use the latest version of all those plugins, most of them having been released before that date. I don't know if this was intentional or not... Let's hope it's not because of unsure quality of latest plugin versions ;-) Anyways, I decided to upgrade to the latest available version for all plugins.

Reporting Plugins

Here's the list for plugins related to site reports:

• cobertura-maven-plugin: 2.3
• findbugs-maven-plugin: 2.3
• jdepend-maven-plugin: 2.0-beta-2
• maven-checkstyle-plugin: 2.4
• maven-jxr-plugin: 2.1
• maven-pmd-plugin: 2.4
• maven-project-info-reports-plugin: 2.1.2
• maven-surefire-report-plugin: 2.4.3
• taglist-maven-plugin: 2.4

I'm going to show some tips and issues when upgrading to these versions in an upcoming post...

Read More

Unit and Integration Testing with Maven, Part 2

Welome Back...

... to the second installment of this little series. After having seen the requirements and hassles when using Maven for testing in the last post, we are now going to list the possible solutions.

Remember, Maven does support different phases for unit and integration tests, but there is only one source directory (usually src/test/java), making it a bit difficult to setup and organize test environments. Hence, we have to use some way to separate both types of test.

Option 1: Separate Module for Integration Tests

In case you are using modules for your project anyways and want to have integration tests which are testing these modules in integration, this is the natural solution: just create another module that depends on the other ones and only contains the integration test sources and resources.

However, if you instead want to integration-test each module individually, this approach just doubles the number of modules, which can be difficult to manage. You could put all integration tests into one big module – but that has other disadvantages, of course.

Since we do not have any sources (only test sources) in that integration-test project, the usual build lifecycle would execute a lot of unneeded steps like copying resources, compiling, testing, creating JAR file etc. We could use the POM packaging type to suppress all of this, but then we have to configure the maven-compiler-plugin to force compilation of test sources.

Independantly of packaging type, we have to do some more configurations:

• Execute Surefire plugin in integration-test phase.
• Prepare integration tests (for instance, start the container and deploy the application) in pre-integration-test phase. This is quite easy with Cargo Maven plugin.
• Shutdown integration tests (stop the container) in post-integration-test phase.

Here is the relevant part of such a POM file:

<build>
  <plugins>

    <!-- *** Compiler plugin: we must force test compile because we're using a 
             pom packaging that doesn't have this lifecycle mapping. -->
    <plugin>
      <artifactId>maven-compiler-plugin</artifactId>
      <executions>
        <execution>
          <goals>
            <goal>testCompile</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

    <!-- *** Surefire plugin: run integration tests *** -->
    <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <executions>
        <execution>
          <phase>integration-test</phase>
          <goals>
            <goal>test</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

    <!-- *** Cargo plugin: start/stop application server and deploy the ear 
             file before/after integration tests *** -->
    <plugin>
      <groupId>org.codehaus.cargo</groupId>
      <artifactId>cargo-maven2-plugin</artifactId>
      <version>1.0</version>
      <configuration>
       ...
      </configuration>

      <executions>
        <!-- before integration tests are run: start server -->
        <execution>
          <id>start-container</id>
          <phase>pre-integration-test</phase>
          <goals>
            <goal>start</goal>
          </goals>
        </execution>
        <!-- after integration tests are run: stop server -->
        <execution>
          <id>stop-container</id>
          <phase>post-integration-test</phase>
          <goals>
            <goal>stop</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

  </plugins>
</build>

Option 2: Different Source Directories

In this scenario, unit and integration test sources are placed in separate source directories, like src/test/java and src/integrationtest/java. I think this would definitely be the best solution, and it actually should be what Maven supports out of the box. Sadly, Maven does not, and as far as I know Maven 3 won't either :-(

Well, we should be able to configure things this way. For compiling and executing integration tests, you would have to configure Compiler plugin to compile the integration test sources in pre-integration-test phase (using the includes parameter), and then configure a second Surefire execution using testClassesDirectory parameter to point it to the integration test folder.

However, this option seems a bit fragile to me. Even if it works (I haven't checked), the integration test folder would probably not show up in Eclipse when using m2eclipse plugin and other plugins may have issues with this additional test source path as well. That's why I do not recommend this option.

Option 3: Different File Name Patterns

In this scenario, the package or file name is used to distinguish between unit and integration test source files. Let's say, for instance, that all integration test classes start with IT* and hence the filename pattern is **/IT*.java. We'd have to configure the Surefire plugin to execute twice: once in test phase for executing the unit tests only, and another time in integration-test phase to execute, well, the integration tests (and only those)

A common way to do so is this:

• In configuration of Surefire plugin, set skip parameter to true to bypass all tests.
• Add an execution element for unit tests, where skip is set to false and exclude parameter is used to exclude the integration tests.
• Add another execution element for integration tests, where skip is set to false and include parameter is used to just include the integration tests and nothing else.
• Prepare and shutdown of integration tests are like before.

Here is the POM section:

<build>
  <plugins>

    <!-- *** Surefire plugin: run unit and integration tests in 
             separate lifecycle phases, using file name pattern *** -->
    <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <configuration>
        <skip>true</skip>
      </configuration>
      <executions>
        <execution>
          <id>unit-test</id>
          <phase>test</phase>
          <goals>
            <goal>test</goal>
          </goals>
          <configuration>
            <skip>false</skip>
            <excludes>
              <exclude>**/IT*.java</exclude>
            </excludes>
          </configuration>
        </execution>

        <execution>
          <id>integration-test</id>
          <phase>integration-test</phase>
          <goals>
            <goal>test</goal>
          </goals>
          <configuration>
            <skip>false</skip>
            <includes>
              <include>**/IT*.java</include>
            </includes>
          </configuration>
        </execution>
      </executions>
    </plugin>

    <!-- *** Cargo plugin: start/stop application server and deploy the ear 
             file before/after integration tests *** -->
    ...

  </plugins>
</build>

There is another approach to achieve the same result:

• In configuration of Surefire plugin, use the exclude parameter to exclude the integration tests when executing unit tests in test phase.
• Add an execution element for integration tests, where exclude is set to any dummy value (to override the default configuration) and include parameter is used to just include the integration tests and nothing else.

It's a bit shorter than the former configuration, but in the end it's a matter of taste. Again, here is the POM snippet:

<build>
  <plugins>

    <!-- *** Surefire plugin: run unit and integration tests in 
             separate lifecycle phases, using file name pattern *** -->
    <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <configuration>
        <excludes>
          <exclude>**/IT*.java</exclude>
        </excludes>
      </configuration>
      <executions>
        <execution>
          <id>integration-test</id>
          <phase>integration-test</phase>
          <goals>
            <goal>test</goal>
          </goals>
          <configuration>
            <excludes>
              <exclude>none</exclude>
            </excludes>
            <includes>
              <include>**/IT*.java</include>
            </includes>
          </configuration>
        </execution>
      </executions>
    </plugin>

    <!-- *** Cargo plugin: start/stop application server and deploy the ear 
             file before/after integration tests *** -->
    ...

  </plugins>
</build>

Failsafe Plugin

Instead of using the Surefire plugin with custom filename pattern to distinguish between unit and integration test classes, you should rather use the Failsafe plugin for executing integration tests.

This plugin is a fork of the Surefire plugin designed to run integration tests.
It is used during the integration-test and verify phases of the build lifecycle to execute the integration tests of an application. Other than Surefire plugin, the Failsafe plugin will not fail the build when executing tests thus enabling the post-integration-test phase to execute.

Failsafe plugin has its own naming convention. By default, the Surefire plugin executes **/Test*.java, **/*Test.java, and **/*TestCase.java test classes. In contrast, the Failsafe plugin will look for **/IT*.java, **/*IT.java, and **/*ITCase.java. Did you note that this matches what we used before for our integration tests? ;-)

When using Failsafe, the last POM (of option 3) looks like this:

<build>
  <plugins>

    <!-- *** Surefire plugin: run unit and exclude integration tests *** -->
    <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <configuration>
        <excludes>
          <exclude>**/IT*.java</exclude>
        </excludes>
      </configuration>
    </plugin>

    <!-- *** Failsafe plugin: run integration tests *** -->
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>failsafe-maven-plugin</artifactId>
      <version>2.4.3-alpha-1</version>
      <executions>
        <execution>
          <goals>
            <goal>integration-test</goal>
            <goal>verify</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

    <!-- *** Cargo plugin: start/stop application server and deploy the ear 
             file before/after integration tests *** -->
    ...

  </plugins>
</build>

Of course, Failsafe would also work with first option (separate integration test module).

Conclusion

Well, after having shown all the ways that came into my mind, here are my personal "best practices":

• Use the Failsafe plugin to execute integration tests.
• If keeping integration tests in a separate module feels alright, do so (see option 1).
• If you want to have unit and integration tests in the same module, choose a file or package name pattern to distinguish between both, and configure Surefire and Failsafe plugins accordingly.

Update (2010/02/18)

Note that there is a new version 2.5 of failsafe plugin available with changed group id: org.apache.maven.plugins:maven-failsafe-plugin:2.5. See the plugin site for details. Thanks to stug23 for pointing that out!

Read More

Unit and Integration Testing with Maven, Part 1

Test Types

In my last post, I talked about integration testing with Maven's Cargo plugin and JBoss Application Server. Now let's see how integration testing fits into an overall testing strategy with Maven.

When thinking about tests and testing strategies, there is one important thing to keep in mind: integration tests are not unit tests (even though JUnit may be used to write integration tests). For the sake of completeness, let's pin down the main characteristics of both:

Unit Tests:

• are testing a small piece of code in isolation
• are independant from other tests
• are usually written by software developers
• have to be very fast because they are run quite often

In contrast, Integration Tests:

• individual software modules are combined and tested as a group
• are usually much slower than unit tests because a context has to be established (Spring, database, web server etc.)
• normally are run after unit testing
• may be created by QA team using tools, but also by developers using JUnit test cases (which still does not turn them into unit tests)

Testing with Maven

As you know, Maven Build Lifecycle provides phases both for testing and integration testing. Related phases are:

...
generate-test-sources
generate-test-resources
process-test-resources
test-compile
process-test-classes
test
...
pre-integration-test
integration-test
post-integration-test
...

Unfortunately, Maven does not support separate source directories for both test types. This is really complicating things (as we'll see in a minute). There have been some discussions on how to fix that, but I don't think it made it into Maven 3 (not quite sure, though).

Hence, what we need to have is this:

• Both unit and integration tests have to be compiled by javac.
• Nevertheless, they should be clearly separated from each other by a path or file name pattern.
• Unit tests have to be run in test lifecycle phase, and the build should stop if they do not succeed.
• Integration tests should be run in integration-test phase, and at least the post-integration-test phase has to be run independantly of test result (to be able to shutdown a running container, close database connections etc.).

The next part of this small series will show how these requirements can be met with Maven and what has to be configured, so please stand by...

Read More

Integration test with Maven, Cargo and JBoss

It's Friday...

... and I thought it would be a good idea to setup an integration test of some EJBs we are creating in a new project. Actually, it was not, since it nearly ruined my evening. But eventually I got it to work, and here is how.

To test the EJBs, I need to create an EAR file, deploy that to the application server (JBoss 5.1.0 in our case) and run JUnit test cases against this server. For Maven, I have setup a separate integration-test module for executing the integration test for the following reasons:

• to better separate unit tests (with JUnit) from integration tests (also with JUnit), which simplifies Maven configuration a bit.
• to be able to run this module outside of the normal CI (continuous integration) build due to its lack of performance.

Cargo Maven Plugin

For automatically starting the container, deploying the EAR file and stopping the container when the tests are finished, I use the Cargo Maven plugin. I did this several times before (with Tomcat, though) – so I thought that'd be easy...

Well, when using JBoss, there are some tricks you have to know. Before going into the details, some more information on Cargo.

A Container is the base concept in Cargo. It represents an existing application server runtime, and Cargo hides all the details of the actual server implementation for you. There are two types of containers:

• Local Container: this is executing on the machine where Cargo runs. This can either be an Installed Container which is, well, installed on the local machine and is run in a separate VM, or an Embedded Container that is executing in the same JVM where Cargo is running (currently only supported for Jetty).
• Remote Container: a container that is already running anywhere (local or remote). It's not under Cargo's control and can't be started or stopped by Cargo.

You use a Configuration to specify how the container is configured (logging, data sources, location where to put the deployables, etc). The available configuration depends on the container type:

• Local Configuration: for local containers. There are two local configuration types: Standalone Local Configuration which configures the container from scratch in a directory of your choice, and Existing Local Configuration that re-uses an existing container installation already residing on your hard drive.
• Runtime Configuration: You use a runtime configuration when you want to access your container as a black box through a remote protocol (JMX, etc). This is perfect for remote containers.

In my case, I wanted to use a Local Installed Container with a Standalone Local Configuration, to eliminate dependencies from other deployments.

JBoss with Cargo

Well, and here are the pitfalls when using JBoss in this setting:

1. Experimental: JBoss 5.x is still an experimental container for Cargo. This is a bit strange given the fact that this version is now out for a while, but fortunately not really an issue.
2. Extensive Logging: When Cargo builds the JBoss configuration – remember, I use Standalone Local Configuration so Cargo creates one from scratch – it uses a logging setup (independantly from what is used with your JBoss installation!) that is way too chatty. The console scrolls forever, and things are slowing down in a way that you think everything is stuck in an infinite loop.
   Thus, you have to tell Cargo to use another logging configuration file, which is a bit tricky and not documented very well (see this issue).
   
3. Shutdown Port: Now the container starts up, the tests are run, but after that JBoss AS is not shutting down. It's telling me javax.naming.CommunicationException: Could not obtain connection to any of these urls: localhost:1299, which means the wrong port is used for shutdown. Standard shutdown port is 1099, so we have to tell Cargo to use that port number.

All in all, the configuration now looks like this. Mentioned settings are highlighted. Perhaps this is useful for someone else...

<!-- *** Cargo plugin: start/stop JBoss application server and deploy the ear 
         file before/after integration tests *** -->
<plugin>
  <groupId>org.codehaus.cargo</groupId>
  <artifactId>cargo-maven2-plugin</artifactId>
  <version>1.0</version>
  <configuration>
    <wait>false</wait>
    <!-- Container configuration -->
    <container>
      <containerId>jboss5x</containerId>
      <type>installed</type>
      <home>${it.jboss5x.home}</home>
      <timeout>300000</timeout>
    </container>
    <!-- Configuration to use with the Container -->
    <configuration>
      <type>standalone</type>
      <home>${project.build.directory}/jboss5x</home>
      <properties>
        <cargo.jboss.configuration>default</cargo.jboss.configuration>
        <cargo.servlet.port>${it.jboss5x.port}</cargo.servlet.port>
        <cargo.rmi.port>1099</cargo.rmi.port>
        <cargo.jvmargs>-Xmx512m</cargo.jvmargs>
      </properties>
      <deployables>
        <deployable>
          <groupId>com.fja.ipl</groupId>
          <artifactId>ipl-lc-ear</artifactId>
          <type>ear</type>
        </deployable>
      </deployables>
      <!-- Override logging created by Cargo (which is way to chatty) with default 
           file from JBoss (see http://jira.codehaus.org/browse/CARGO-585) -->
      <configfiles>
        <configfile>
          <file>src/test/resources/jboss-log4j.xml</file>
          <todir>conf</todir>
        </configfile>
      </configfiles>
    </configuration>
  </configuration>

  <executions>
    <!-- before integration tests are run: start server -->
    <execution>
      <id>start-container</id>
      <phase>pre-integration-test</phase>
      <goals>
        <goal>start</goal>
      </goals>
    </execution>
    <!-- after integration tests are run: stop server -->
    <execution>
      <id>stop-container</id>
      <phase>post-integration-test</phase>
      <goals>
        <goal>stop</goal>
      </goals>
    </execution>
  </executions>
</plugin>
<properties>
  <it.jboss5x.home>${basedir}/../../../tools/bin/jboss-5.1.0.GA</it.jboss5x.home>
  <it.jboss5x.port>8080</it.jboss5x.port>
</properties>

Read More

JBoss and Maven

The Challenge

During the last days I was busy trying to build and deploy a JEE application on JBoss – using Maven, of course. One interesting task was to run integration tests, i.e. JUnit tests that are testing a service bean deployed on JBoss application server. Integration tests with Maven are an interesting issue, worth its own blog entry probably. But this post is all about JBoss.

Well, this task doesn't sound hard for a Maven expert, but unexpectedly it was not that easy. Our test code (calling the EJB) was depending on JBoss artifacts, which might be questionable in itself but that's how it's currently done. Hence, during runtime the code needs the jbossall-client.jar from JBoss' client directory in the classpath.

The Eclipse Way

We are using JBoss 5.x, and in this version the jbossall-client.jar is rather small since it only references all required jar files in the Manifest's Class-Path element:

Manifest-Version: 1.0
Specification-Title: JBossAS
Specification-Version: 5.0.0.GA
...
Implementation-Vendor: JBoss.org
Implementation-Vendor-Id: http://www.jboss.org/
Class-Path: commons-logging.jar concurrent.jar ejb3-persistence.jar hi
 bernate-annotations.jar jboss-aop-client.jar jboss-appclient.jar jbos
 s-aspect-jdk50-client.jar jboss-client.jar jboss-common-core.jar jbos
 s-deployers-client-spi.jar jboss-deployers-client.jar jboss-deployers
 -core-spi.jar jboss-deployers-core.jar jboss-deployment.jar jboss-ejb
 3-common-client.jar jboss-ejb3-core-client.jar jboss-ejb3-ext-api.jar
  jboss-ejb3-proxy-clustered-client.jar jboss-ejb3-proxy-impl-client.j
 ar jboss-ejb3-proxy-spi-client.jar jboss-ejb3-security-client.jar jbo
 ss-ha-client.jar jboss-ha-legacy-client.jar jboss-iiop-client.jar jbo
 ss-integration.jar jboss-j2se.jar jboss-javaee.jar jboss-jsr77-client
 .jar jboss-logging-jdk.jar jboss-logging-log4j.jar jboss-logging-spi.
 jar jboss-main-client.jar jboss-mdr.jar jboss-messaging-client.jar jb
 oss-remoting.jar jboss-security-spi.jar jboss-serialization.jar jboss
 -srp-client.jar jboss-system-client.jar jboss-system-jmx-client.jar j
 bosscx-client.jar jbossjts-integration.jar jbossjts.jar jbosssx-as-cl
 ient.jar jbosssx-client.jar jmx-client.jar jmx-invoker-adaptor-client
 .jar jnp-client.jar slf4j-api.jar slf4j-jboss-logging.jar xmlsec.jar

This list is impressive... and the approach is working with current Eclipse. The equivalent for the Maven world would be a POM that references all other required libraries as normal dependencies (see this discussion).

The Maven Way

And yes, such a POM org.jboss.jbossas:jboss-as-client is available on JBoss Maven repository (note: it's not org.jboss.client:jbossall-client which is the reference-by-manifest's-class-path version!).

However, this approach involves two issues:

• By following the dependencies defined in this org.jboss.client:jbossall-client transitively, Maven will download a vast number of JBoss and JEE libraries which you actually don't want to be used and packaged in your client. This includes things like org.jboss.jbossas:jboss-as-server:jar:5.1.0.GA and jacorb:jacorb:jar:2.3.0jboss.patch6-brew. Does not sound confidence-building, does it? Seems like JBoss should exclude transitive dependencies at the right places.
• Moreover, some of the dependencies can't be found on any of the Maven repositories we configured to proxy in our Nexus. This includes Maven Central, JBoss of course, and a couple of others, so I do not know what else to add to provide the missing jars. Maybe it's just that the reference itself is wrong (version number?).

Instead of excluding everything we do not use currently, next idea is to just include those dependencies to the JBoss jar files that the client actually requires. But... it's quite hard to find out the corresponding Maven coordinates. This includes guessing the groupd and artifact id, but also the version – and unfortunately the version information given in the jar's manifest file is not useful since it notes the JBoss AS version instead of the version of the library which is required for Maven.

Lost in Space?

So, I ended up re-packaging a jar that holds the content of the required client jars and putting this on our Nexus...

I honestly wonder how everybody else is using JBoss 5.x with Maven on the client side???

Read More

Spring dm Server Considered Cool?

w-jax is over...

I'm just returning from w-jax 2009, one of the biggest german Java conferences, covering every technology related to Java actually.

If there are any hypes this year, they are these: Scala, Cloud Computing and OSGi. And, of course, Spring – which is all around.

Spring Source employs a lot of brave guys, and hearing first-hand about their newest coolest technologies is always refreshing. Did you know that Tomcat is to a large extent pushed by guys paid by Spring Source? I forgot the exact number, but Eberhard Wolff said the majority of bug fixes and commits is done by Spring Source's Tomcat team.

Spring dm Server is Cool!

There have been some sessions about Spring dm Server, and when taking a closer look it seems to be clear why Spring Source invests in Tomcat that much. Spring dm server is based on Tomcat, and they add the ability to deploy web application modules as OSGi bundles. This way, you can partition your web apps into separate bundles to deploy them independantly and dynamically into the server. Yes, they are preserving OSGi's dynamic, meaning that you can stop, start or refresh a particular bundle without the need to stop and restart the server. As you would expect, other bundles continue to work. If a requested OSGi service is temporarily not available, dm Server will wait 5 minutes for it being redeployed.

Spring dm server is part of Spring Tool Suite, an Eclipse based development environment which is also able to auto-deploy a module whenever it changes.

All of this is quite gorgeous from a technical perspective, and the Spring guys had to cope with some really hard issues (for instance, realted to JPA where they need an application wide visiblity of bundles as well as load time weaving – you won't want to know the details...).

Really? What for?

But... is this really of any interest in the field?

Our customers are using WebSphere (or WebLogic or maybe JBoss) application server, and all of them are not capable of running such a modularized, OSGi based application. Moreover, in a production environment, there is no need and most often it is actually not even desired to be able to refresh application bundles dynamically.

So, what's left? Modularizing your application? Right, that is leading to a better structure and less coupling and blah blah, but the same can be achieved without OSGi (just let the business domain drive your application "slices"). It's just that you are forced to use modules (bundles) when you are using OSGi.

If at all, Spring dm server will pay off for developers since it may speed up development (especially the build-deploy-test cycle). But is this really, I mean really, hurting us that much? Hence, if you were asking me, a lot of technical overhead and server lock-in for no real benefit.

So, will Spring dm server be able to gain real attention, I mean beyond being technically cool? I'm sceptical. As always, time will tell...

Read More