Revision 494201 (trunk) has a working JUnit based upgrade test that handles multiple old versions and does not hit sealing issues seen by the older harness based test.
The test uses the same property to specifiy the location of the old released jars but in a different way to the old test.
The old test used
The new setup uses (to allow multiple releases at the same major.minor
The set of old releases tested against is given by a list in _Suite. This was to allow a releases folder to contain a number of previous releases and have derbyTesting.jar.path point to it.
I have not changed the tools/testing folder to the new scheme, this new JUnit upgrade test does not yet include all the cases from the old test. If we wanted to switch to the new scheme incrementally then I could change the property used by the JUnit test to something else (e.g. derbyTesting.oldReleases) and then we could run the tests in parallel until the new one is a super-set of the old.
The test can be run as a standard JUnit test., though it has to be run using the _Suite class:
If the system property derbyTesting.jar.path is not set, then no tests will be run.
If for an old release the folder $
/M.m.f.p/lib does not exist then that old release will be skipped.
It's not hooked up into any standard run (e.g. suites.All) due to the changes need to jar layout and that in trunk upgrading from 10.0 fails (need to check out why).
'm also not sure if all the old releases should be in a code line, or just a sub-set. The test would handle either situation and maybe running all the old versions could be left to those that want to (by pointing the property to a folder with all the old releases).
(BTW currently with five old releases the test takes around 25 seconds)