[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-dev] Recent changes...
|
The root properties file duplicates the framework jarname definitions. The individual test project's properties currently defines the jarnames it depends upon.
However, since most builds start at the root level, the root property definitions will be applied, and the test property definitions that have already been defined will not be overridden.
In the case where the individual modules are called independently, they will also have all the definitions they need, so yes it will still work.
-Eric
On 23/03/2012 9:36 AM, Edwin Tang wrote:
Hi Eric,
"While the framework jarnames are also defined in the root properties file, most of the needed test jarnames are only defined in the local properties file of the module in question."
Is the root properties file loaded by module antbuild files? It was wondering if executing "ant -f antbuild.xml" from a test module directory can still build tests correctly.
Thanks,
Edwin
-----Original Message-----
From: Eric Gwin
Sent: March 23, 2012 8:11 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: [eclipselink-dev] Recent changes...
Hello all,
I wanted to send this out so you'd be aware of a few testing changes. Yesterday I completed a fix for Kevin that among other things involved splitting the core and jpa testing jars. In both cases the framework classes were removed and put into separate jars, also all the "test" jars were renamed to "eclipselink-<module>-tests.jar" rather than the previous generic "eclipselink-tests.jar" that was used in most cases. In all cases, the build files use variables to represent the jarname. While the framework jarnames are also defined in the root properties file, most of the needed test jarnames are only defined in the local properties file of the module in question.
The overall change allows differentiation of testing jars, and removes inter-module testing jar dependencies where only the framework classes were needed (the only exception was in the case of oracle extension testing, where the tests depend upon the core models as well as the core framework - maybe a general split between framework, models and tests should be considered).
As a side-effect of this work, it may become easier to split-away the various test framework code modules from the actual test modules and create test framework project(s) - not planned at this point.
-Eric
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
