Dear All 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 jbossmessagingtests.jar 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 respoitory.jboss.com 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 build-thirdparty.xml. 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 proposed change. 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 $JBAS/testsuite/src/org/test/jboss/test/jbossmessaging If there are no objections, we aim to incorporate the first set of changes late tomorrow (Friday, 1 September). Richard 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 : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968806#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...