The JBAS testsuite presently executes integration tests for the JMS provider JBossMQ, but
not for the new JMS provider Messaging. This topic concerns changes to the testsuite to
incorporate integration tests for Messaging.
Adding these tests to the testsuite involves the following steps:
1. create a new directory $JBAS/testsuite/src/main/org/jboss/test/jbossmessaging to hold
the new integration tests and define an appropriate patternset
2. import the Messaging artifacts (e.g. jboss-messaging.jar) from repository.jboss.com
into $JBAS/thirdparty (Messaging is no longer built within the JBAS build)
3. modify the tests.classpath to incorporate the new Messaging artifacts so that the new
test classes are correctly compiled by the target compile-classes-only and make changes to
$JBAS/testsuite/src/imports/test-jars.xml to create a suitable jar file
4. create a new messaging configuration
6. start up JBAS with the new configuration, call run-junit with the patternset to execute
the tests and then shutdown the JBAS server
Steps 2 & 3 involve testsuite independently importing Messaging artifacts from
into $JBAS/thirdparty. A mechanisms for doing this was incorporated
into the testsuite/build.xml file in svn.repository.com/repos/jbossas/branches/Branch_4_0
making use of a new target createthirdparty in testsuite/build.xml and a new file
The target checks if the thirdparty directory is up to date, and calls
build-thirdparty.xml if it is not. It also generates a file
thirdparty/testsuite-libraries.ent containing path definitions for the new thirdparty
entries. This mechanism allows testsuite to independently make use of thirdparty libraries
from the repository. However, if you need to add those libraries to the key testsuite
classpaths, there is a problem, as the key classpaths (e.g. tests.classpath) get
constructed before any targets are executed, including createthirdparty. What we propose
is to force the classpaths to be built after createthirdparty has had a chance to execute
by defining a target createclasspaths in which all the key testsuite claspath targets are
built and which gets executed after createthirdparty. Dependencies will be added to ensure
that the overall desired testsuite behaviour does not change. This will allow
testsuite-libraries.ent to be included and used in a more flexible manner. This is one
Step 4 involves creating a new messaging configuration. An existing ant script for doing
this, release-admin.xml, is already present in the Messaging build. Rather than duplicate
this code in the testsuite build, we propose to import release-admin.xml just as any other
Messaging artifact, bring it into the $JBAS/testsuite/src/resources directory, and execute
it to create the nmessaging configuration. This is a second proposed change.
We would like to incorporate these changes as follows:
1. Make the changes to allow testsuite to independently import and use thirdparty
libraries. Commit the changes and monitor builds for a few days.
2. make the changes to allow release-admin.xml to be imported and executed. Commit the
changes and monitor for a few days.
3. Continue adding tests cases for Messaging to
If there are no objections, we aim to incorporate the first set of changes late tomorrow
(Friday, 1 September).
PS Please excuse the brevity - my first version of this posting, much more detailed and
taking over an hour to write, was sent into the ether by the Preview button.
View the original post :
Reply to the post :