Community
Participate
Working Groups
In build.properties file under /trunk/jpa/eclipselink.jpa.wdf.test directory, "junit.lib" was defined like "junit.lib=../../../extension.lib.external/junit-4.5.jar". Usually just has junit.jar under extension.lib.external directory, and we always keep update this junit.jar to be the latest version. It's better to change use junit.jar instead of unit-4.5.jar in build.properties.
The proposed change is fine with me.
Code reviewed by Adrian Görler. Checked in trunk, revision: 6587.
The primary reason the process used junit.jar rather than junit4.5.jar was that junit did not provide versioned jars, as a result our process evolved to not make use of them. However, there are instances where this is a pain. Now that junit has changed thier standard to include version info in the jar name, It was proposed and accepted that we adopt the versioned name as standard. We do have a built-in mechanism to bypass this for processes that will require a junit.jar (no version), such as oracle-side testing. That is to use the user.home/build.properties file to define junit.lib to <path>/junit.jar ( or <path>/foo.jar if you'd like ;) ). However the default should remain the versioned file.
I totally agree with Eric's suggestion, and that will force user to use the latest or specific version of junit jar to run test and developing. But I have found there are lots of properties file use non-version junit.jar in junit.lib path, it's hard to maintenance when the version of junit.jar have changed (we need to change all properties file with "junit.lib" setting). If there is junit.lib setting in the properties file in trunk level, and all other properties files just call junit.lib defined in trunk level, we only need to update one properties file when new version junit.jar is coming. The above is just my thinking, probably Eric have better idea, and this should belong to building enhancement, so I assigned it to Eric.
AFAICT there is this higher level problem of having one setting for all suites remaining, but that is to be solved in a different but.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
