Derby
  1. Derby
  2. DERBY-6078

Propagate a set of properties to the junit tasks in build.xml

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.10.1.1
    • Fix Version/s: 10.9.2.2, 10.10.1.1
    • Component/s: Test
    • Labels:
      None

      Description

      At times it would be very helpful to be able to specify a set of properties to pass on to the JUnit tests when invoking the JUnit tasks in build.xml. Examples are specifying a non-default port to use, to shorten down the run-time of the stress-test,or to specify the location of old release jars (this is already handled explicitly).

      There are several alternatives on how to do this - see http://ant.apache.org/manual/Types/propertyset.html for details.
      I suggest we try out the simplest approach first: pass on any system properties set on the command line. It should be very simple to implement. The downside is that a property you specify for the higher-level build script may interfer or be in conflict with the running of the tests.

        Activity

        Hide
        Knut Anders Hatlen added a comment -

        I merged the fix to 10.9 and committed revision 1486816.

        I plan to use it to pass the derby.tests.basePort property to the Jenkins build jobs to prevent port conflicts, as discussed in this thread: http://mail-archives.apache.org/mod_mbox/db-derby-dev/201305.mbox/%3C51A4333E.7040801%40oracle.com%3E

        Show
        Knut Anders Hatlen added a comment - I merged the fix to 10.9 and committed revision 1486816. I plan to use it to pass the derby.tests.basePort property to the Jenkins build jobs to prevent port conflicts, as discussed in this thread: http://mail-archives.apache.org/mod_mbox/db-derby-dev/201305.mbox/%3C51A4333E.7040801%40oracle.com%3E
        Hide
        Kristian Waagan added a comment -

        Committed patch 1a to trunk with revision 1448359.

        Show
        Kristian Waagan added a comment - Committed patch 1a to trunk with revision 1448359.
        Hide
        Knut Anders Hatlen added a comment -

        Looks like a useful improvement. +1

        Show
        Knut Anders Hatlen added a comment - Looks like a useful improvement. +1
        Hide
        Kristian Waagan added a comment -

        Patch 1a shows how the functionality can be implemented.

        I tested it by specifying an invalid value for derbyTesting.oldReleasePath and running the upgrade tests with junit-single:

        $ ant -DderbyTesting.oldReleasePath=/asdasd7asdasd -Dderby.junit.testclass=org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite junit-single
        ...
        junit-single:
        [junit] ALARM: Non-existing location for jar files: '/asdasd7asdasd\10.0.2.1'. Upgrade tests can NOT be run!
        ...

        Show
        Kristian Waagan added a comment - Patch 1a shows how the functionality can be implemented. I tested it by specifying an invalid value for derbyTesting.oldReleasePath and running the upgrade tests with junit-single: $ ant -DderbyTesting.oldReleasePath=/asdasd7asdasd -Dderby.junit.testclass=org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite junit-single ... junit-single: [junit] ALARM: Non-existing location for jar files: '/asdasd7asdasd\10.0.2.1'. Upgrade tests can NOT be run! ...

          People

          • Assignee:
            Kristian Waagan
            Reporter:
            Kristian Waagan
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development