EJBTHREE-1998: TestSuite Client Dependencies from JBOSS_HOME

[alrubinger]

I've committed the patch for EJBTHREE-1998 which builds the test client classpath from artifacts under JBOSS_HOME.

Note that if libraries move around between AS targets (ie, EAP and As trunk), we'll need to continue to keep the build-test.xml paths backwards-compatible to support both.

For now the tests are coming back mostly OK I think, though the view is clouded due to CNFE on some stuff from Hibernate Core.  This should be temporary; the mapper responsible for removing version numbers from JAR names in the AS build is not handling "SNAPSHOT" properly, and Hibernate in AS is now a snapshot.

Tomorrow there should be a release cut and we'll see where we stand.

S,

ALR

[jaikiran]

ALRubinger wrote:

For now the tests are coming back mostly OK I think, though the view is clouded due to CNFE on some stuff from Hibernate Core.  This should be temporary; the mapper responsible for removing version numbers from JAR names in the AS build is not handling "SNAPSHOT" properly, and Hibernate in AS is now a snapshot.

I'll take a look at this today. I remember seeing something like this locally around a month back, but hadn't spent much time on it. One of the reasons why AS is using the hibernate SNAPSHOT is to run our EJB3 testsuite and the AS testsuite to identify any genuine regressions, before going for a Hibernate release. So getting a clean EJB3 testsuite run is going to help

The other reason why the mapper has to be fixed is because, even though the AS doesn't allow SNAPSHOT version to be included in the component-matrix, i keep using SNAPSHOT on my local checkout of AS trunk (and i believe others do too). So if there's a bug around that, then fixing it will help.

[jaikiran]

Any specific reason why we are adding individual jars from the JBOSS_HOME to the classpath, instead of just adding the JBOSS_HOME/client folder to the classpath. Something like this, which i did to get the testcases passing:

[jpai@localhost testsuite]$ svn diff build-test.xml
Index: build-test.xml
===================================================================
--- build-test.xml      (revision 100789)
+++ build-test.xml      (working copy)
@@ -325,6 +325,7 @@
   <path id="client.classpath">
 
     <!-- JBoss Client Binaries -->
+    <fileset dir="${location.client.lib}" includes="*.jar"/>
     <pathelement path="${location.client.lib.commons-logging}" />
     <pathelement path="${location.client.lib.jbossall}" />
     <pathelement path="${location.client.lib.jbossxb}" />

Ideally, it should have been just JBOSS_HOME/client/jbossall-client.jar. But i see that the MANIFEST.MF of that jar is incomplete. So why not just JBOSS_HOME/client/*.jar. That way, we don't have to keep changing our build file if the jar file names changes (like in this SNAPSHOT case).

If there are no objections, then i'll commit this patch (and also remove any subsequent, redundant pathelements from the classpath).

[alrubinger]

I thought I'd once seen some tests relying upon internals not covered by $JBOSS_HOME/client.  But I agree, that's much better to start with all client libs and then add something else if necessary (plus less prone to breakage).

S,

ALR

[jaikiran]

I have now commited that patch. Hibernate/AS team is waiting for a clean run from the EJB3 testsuite, so i haven't spent more time on removing and testing any redundant classpath entries. And also, there's a discussion going on about why the jbossall-client.jar has only selective jar entries http://community.jboss.org/thread/147934 . Once we have an answer on that, then maybe it would just be a matter of using jbossall-client.jar in the classpath.