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:
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
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-clienttransitively, 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
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???