RE: [eclipselink-dev] I need your views (Test Build changes)...

[Peter Krogh <PETER.KROGH@xxxxxxxxxx>]

I have scheduled a meeting for 2:00est on Monday Nov 16th.

If you wish to attend this meeting and the time does not work for you, please let me know.

-----Original Message-----
From: Gordon Yorke 
Sent: Thursday, November 12, 2009 3:02 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] I need your views (Test Build changes)...


We should not be throwing the 'kitchen sink' at the classpath.  
Dependencies need to be planned for, tracked and approved.  Having the 
test scripts ensure that only the expected dependencies are available to 
a set of tests ensures that we do not introduce unexpected dependencies.

The tests can always be run against the test classes but should always 
run against the deliverables for the component and any dependencies.  
Although we should add a test target for developers that can run against 
the classes directories the main target should run against the 
eclipselink.jar.

Also I do not understand why we would need special tests to test for the 
eclipselink.jar.  If you are running the main target and the 
eclipselink.jar is not available the tests should fail to run at all.

Perhaps a conference call could work this all out.  Perhaps Peter can 
make arrangements for a conference call on this issue early next week?
--Gordon

Eric Gwin wrote:
> Two idealogical items were brought up this week regarding the test 
> builds (I've specifically added an assumed third (disallowing classes)):
>
> 1. What to test against:
>    - Most tests used to throw the kitchen sink into the classpath to 
> get them to work (eclipselink.jar, bundles, and classes
>      as well as all possible dependencies)
>    - SDO and MOXy always test nightly against the eclipselink.jar only
>    - To get the rest of the tests working, without a recompile of the 
> product, tests  have been added to verify the existence
>       of  eclipselink, the bundles, and the classes. Then one set is 
> used in the classpath (in order of preference):
>          eclipselink.jar, the bundles, or classes
>       - The same target is executed regardless of classpath.
>  - I included the bundle set in anticipation of testing against OSGi 
> platforms, and because we seem to be promoting the
>     targeted use of eclipselink as an added configuration (therefore 
> we will need the capability of certifying the bundles)
>  - Given the new directive for testing to not recompile the product it 
> seems, it can easily be extended to include
>    "tests should only be run against product jars" (eclipselink, or 
> bundles) when using ant (eclipse testing
>    remain unaffected).
>
> 2. Dynamic vs Static Testing
>    Rather than running a test target against any available set of 
> product classes (eclipselink.jar, the bundles, or class dirs), a
>    preference has been stated to use static targets for a 
> configuration set.
>    - The reason is to ensure that you are testing against what you 
> think you are. For example "test-srg-using-jar" would only
>       and always run the SRG against the product jar, 
> "test-srg-using-bundles" and "test-srg-using-classes" would only test
>      against the bundle jars and classes respectively.
>       - The down-side is that scripts would need to be focused for a 
> specific methodology, and couldn't be reused for multiple purposes.
>
> To limit impact on testing and development I had been approaching the 
> reorg design utilizing a dynamic approach. I can see the benefit for 
> going to a static approach, but I need your input first.
>
> I can also see a benefit to disallowing class testing, but the 
> rigidity may cause problems later. Certainly product-only defaults can 
> be setup.
>
> Irregardless of the outcome, I plan on continuing to test availability 
> first and report a missing dependency in the effort to increase 
> usability and robustness, as well as reduce debug time.
>
> Anyone have strong preferences?
> -Should the tests dynamically target the product using a single 
> target, or should configuration-specific static targets be used?
> -Should testing against jars be enforced? If so does this include 
> testing jars (vs allowing test classes) (in some cases this is
> already necessary, in others it is not)?
>
> -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