9 Replies Latest reply on Mar 12, 2007 10:07 PM by ryan.campbell

    Test suite classpath normalization

      While the test suite allows you to test the server binaries available under jboss.dist, it does not allow you to test the client jars available under ${jboss.dist}/client. Instead, the client classpath is essentially all the jars either:

      1. Produced by the build under */output/lib
      2. Downloaded in /thirdparty

      This prevents you from testing the client jars under ${jboss.dist} and fully validating that image which is useful for many different applications including patch testing and the testing of various installation techniques. Perhaps just as important, it will allow us to detect inadvertent omissions.

      I have created http://jira.jboss.com/jira/browse/JBAS-3993 which suggest we should source the tests.classpath primarly from ${jboss.dist}/client/*.jar, and only supplement as needed for test cases which require additional jars.

      I propose the following approach:

      - rename the existing tests.classpath to tests.compile.classpath
      - create a new tests.classpath which is intially only contains ${jboss.dist}/client/*.jar
      - add additional jars as needed. I would expect things like apache HTTPClient. Each of these exceptions should be listed in this thread so we are aware of what they are.

      This should first be implemented in Branch_4_0, then 4_2, then trunk. Most of the task will be identifying which additional jars must be added to the classpath besides ${jboss.dist}/client/*.jar and verifying this work causes no regressions.

        • 1. Re: Test suite classpath normalization
          starksm64

          This is needed, but we should be building more test group specific client classpaths to better track what tests require what jars from the client dir.

          Note that some tests do rely on server jars at they try to tests implementation details. These tests should be moved into the corresponding module they are testing the implementation of.

          We are starting to include more tests in modules, so we need a way to run these tests as part of the overall qa tests.

          • 2. Re: Test suite classpath normalization

            Ok, so it sounds like you want something like several of these:

            <test-target>.classpath

            where <test-target>.classpath is the ant target with dashes converted to dots. So we would have:

            jboss.all.config.tests.classpath
            tests.security.manager.classpath
            tomcat.ssl.tests.classpath
            etc...

            We will come up with estimates for the monolithic test classpath vs. group level classpaths. The monolithic test classpath will meet our immediate needs, but I realize the group level classpaths provide better documentation and better analysis of depdencies.

            Good point on the server jars, they could be included from ${jboss.dist} as well.

            As for the tests in other modules, this goes back to isolating the test harness/refactoring the test suite. This is in scope for the near future, but I'd like to keep that discussion separate.

            • 3. Re: Test suite classpath normalization
              starksm64

               

              "ryan.campbell@jboss.com" wrote:
              Ok, so it sounds like you want something like several of these:

              <test-target>.classpath

              where <test-target>.classpath is the ant target with dashes converted to dots. So we would have:

              jboss.all.config.tests.classpath
              tests.security.manager.classpath
              tomcat.ssl.tests.classpath
              etc...

              We will come up with estimates for the monolithic test classpath vs. group level classpaths. The monolithic test classpath will meet our immediate needs, but I realize the group level classpaths provide better documentation and better analysis of depdencies.

              Sounds good.

              "ryan.campbell@jboss.com" wrote:

              As for the tests in other modules, this goes back to isolating the test harness/refactoring the test suite. This is in scope for the near future, but I'd like to keep that discussion separate.

              Ok.


              • 4. Re: Test suite classpath normalization
                pavel.tsekov

                Are there any tests in the testsuite that require .jar libraries from ${jboss.dist}/client ?

                • 5. Re: Test suite classpath normalization
                  starksm64

                  Not currently as the testsuite classpath is built from the jbossas module classpaths.

                  • 6. Re: Test suite classpath normalization

                    Right, so instead of building the classpath from jbossas module classpaths, we want to build it primarily from ${jboss.dist}/client. All tests will then require .jar libraries from ${jboss.dist}/client.

                    • 7. Re: Test suite classpath normalization
                      mvecera

                      Hello,

                      I have an idea I would like to discuss here. I copied tests.classpath to tests.compile.classpath. Then I added all jar files in build/output/JBoss-xxx/client/ at the beginning of test.classpath.

                      Now using tests.compile.classpath for compiling tests and tests.classpath for running tests should result in desired behavior, shouldn't it?
                      Because java searches for the first location of class in classpath it should use maximum of client/*.jar files.

                      Is this correct?

                      • 8. Re: Test suite classpath normalization
                        starksm64

                        Yes, that is correct.

                        • 9. Re: Test suite classpath normalization

                          The patch on the http://jira.jboss.com/jira/browse/JBAS-3993 looks good to me and should be applied to all branches:

                          Branch_3_2
                          Branch_4_0
                          Branch_4_2
                          /trunk