Scott,
I think that it is best if you put the sources of the Contributions into some separate modules that
are built separately to create Contribution ZIPs that are then used as dependencies by the tests.
This is effectively what we do in the OASIS testcases, where there are loads of Contribution ZIPs
that are then used by the testcases thenmselves.
You must be able to see how the Contributions are built from sources - and be able to change the
Contributions in the case where errors or updates need dealing with.
This may even be desirable from a test perspective in that sharing of contributions between
different testcases may be possible, reducing the overall pile of materials - this too is done in
the OASIS tests and makes a big impact on the number of artifacts required, especially in the
Assembly testcases.
Yours, Mike.
PS. Don't feel inhibited to beg steal or borrow any of the OASIS materials. They can be freely
reused and contain some entertaining artifacts at the level of both Composites and Implementations.
On 23/06/2011 16:54, Scott Kurz wrote:
Quick question:
I noticed a bug on the path used by binding-sca-runtime when doing a
cross-classloader (e.g. cross-Contribution) copy.
Not sure how important it is to people to keep the tests structured
relatively simply...
I'm thinking I'll add the test to the binding-sca-runtime module and
just check-in a couple contribution JARs as source, since that's
easier to me than trying to build/copy/package things in two JARs.
(I see some modules e.g. 'contribution' checking in JARs as source).
Kind of ugly not to have the Java as source though...
Does anyone have a better suggestion on where to add a test for this case?
Thanks,
Scott
