The requirement from the QA side is quite simple, i.e., being able to easily access the EclipseLink product jars built by the nightly build, and run all the tests without rebuilding the product jars.
To be more specific, the senerio is like:
* Revision (a) is the SVN revision which the nightly build is based on
* Revsion (b) is the SVN revision created by check-in(e.g., eclipselink.jar and so on) in the nightly build
* SVN update to revision (b), or plus minimum extra step(s), the EclipseLink product jars built by the nightly build are expected in their places for testing
Since the nightly build happens in the midnight, mostly (b)=(a)+1, in rare cases, there are revisions(check-ins) between (a) and (b), that could protentially cause mismatch of runtime and test when testing on revision (b).
Thanks,
Edwin
-----Original Message-----
From: Eric Gwin
Sent: November 10, 2009 3:00 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] I'd like to move the test framework code.
This work is independent of the 2nd goal (Step 1 of which is actively
under development).
However, I'll take a stab at a rough outline. QA needs to participate in
the process to flush out all the requirements
Step1: test builds need to be able to detect what to test against (jar,
bundles, or classes; for nightly testing, OSGi testing, and dev testing
respectively). It is currently setup such that if the product jar is
found it is used, if not the bundles are searched for, if that still
fails the class files are used, or the build fails (core and oracle
currently work this way; updating others as they are converted). I'd
like to do JPA next, but it is huge, often modified, and the least stable.
Step2: mechanisms need to be put into place to retrieve the product for
testing. I'm thinking since we already have the maven infrastructure in
place that would be a good place to start, though I'm not familiar with
all the requirements from the QA side. The end solution would need to
work (or be workable) for all scenarios.
-Eric
Edwin Tang wrote:
> I am interested in the road map of achieving the 2nd goal:
> - allow them to run without recompiling the EclipseLink product jar(s).
>
> -Edwin
>
> -----Original Message-----
> From: Eric Gwin
> Sent: November 10, 2009 8:29 AM
> To: Dev mailing list for Eclipse Persistence Services
> Subject: [eclipselink-dev] I'd like to move the test framework code.
>
>
> Hi,
>
> I am currently working on the testing builds, with two goals:
> - bring them up to the agreed standards of the product builds, and
> - allow them to run without recompiling the EclipseLink product jar(s).
>
> During this effort, it has become apparent, that with a little more work
> things could be made much easier for testing - both for our team, and
> for users of EclipseLink. One of the things that would make testing
> easier is to separate tests from the testing infrastructure. This would
> allow the infrastructure to be built once and depended upon by the
> tests, rather than having the test projects rely on a spaghetti plate of
> inter-dependencies.
>
> The change for development should simply mean another project in eclipse
> that needs to be added once before tests will compile.
>
> I've opened
https://bugs.eclipse.org/bugs/show_bug.cgi?id=294732 to
> track discussion about this issue. Please comment. I want to find out if
> there is any pressing reason or strong opinions not to do this.
>
> Thanks.
>
> -Eric
> _______________________________________________
> eclipselink-dev mailing list
>
eclipselink-dev@...
>
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev> _______________________________________________
> eclipselink-dev mailing list
>
eclipselink-dev@...
>
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev>
>
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
