test/lib split in distribution - WAS Re: Running a Derby JUnit test using JUnit directly

[Daniel John Debrunner <dj...@apache.org>]

Myrna van Lunteren wrote:

> On 9/1/06, Daniel John Debrunner <dj...@apache.org> wrote:
> 
>> Vemund Ostgaard wrote:
>>
>> > For the jobs doing nightly testing on the 10.2 branch we did a short
>> > term workaround by copying derbyTesting.jar to its old location, to
>> > avoid other changes. So, thats why it hasn't failed in those tests.
>>
>> It's good to report such problems, not just work-around them. That way
>> others get to know and the issue can be fixed quicker.
>>
>> Or maybe I missed the e-mail discussing this?
>> Dan.
>>
>>
> This is a good catch - I had just continued my practice from earlier
> versions to copy all derby*.jar files to one location and set my own
> classpath, I never thought about verifying with the split set-up.
> 
> I think the harness/policyfile should work either way...

The changes I'm making will make that so.

> 
> Now that we know of the problem, I have to say I prefer the jumble
> approach, especially when the need arises to run on a number of
> different machines.

Why? Just trying to understand why you prefer it, you say you do but
provide no reason why. :-) Kind of like a veto with no reason!

The reason I entered the improvement to have the split was so that users
of Derby who want to re-distribute it will have a clear separation as to
what was needed for the database "product" code and what was for the
tests. This becomes increasingly important in the future as more
non-derby jars are shipped with Derby, e.g. I could see in the future
having (assuming licencing is ok for any jar):

   - lucene jar for text indexing
   - oro jar for the harness (done today in test)
   - junit jar
   - apache commons jar to pick up soundex code

I believe that if all of these are lumped in lib or even lib/3rdparty
then it's really unclear which are just needed for the tests, and the
default action will be someone to ship all of it, and then complain
about the footprint.

I also believe that there should be a very easy setup for users to run
all the tests, something like the derbyrun we have today for ij etc. So
that any one can run the derby tests from a distribution doing something
 like:

     java -jar test/derbyTesting.jar

This ties into the split as it obviously requires Derby distribution to
contain all the jars required by the test runs.

This would be a default test setup run, the "common case", it would not
cater for all situations, such as the remote host running you do, or
testing running the 10.2 tests against 10.3, which are important but
less likely for users of Derby to do.

Thanks,
Dan.

Re: test/lib split in distribution - WAS Re: Running a Derby JUnit test using JUnit directly

[Myrna van Lunteren <m....@gmail.com>]

On 9/1/06, Daniel John Debrunner <dj...@apache.org> wrote:
> Myrna van Lunteren wrote:
>
> > On 9/1/06, Daniel John Debrunner <dj...@apache.org> wrote:
> >
> >
[snip]
> > Now that we know of the problem, I have to say I prefer the jumble
> > approach, especially when the need arises to run on a number of
> > different machines.
>
> Why? Just trying to understand why you prefer it, you say you do but
> provide no reason why. :-) Kind of like a veto with no reason!

Apologies, I didn't imply to veto anything. I like the jumble of
course because of habit, but I find it convenient and logical when
having to run derbyall on a number of rarely used machines, to have
all derby*.jar of a specific version and jars in one dir, one level
deep, with a nice breezy dir name like '102b1'. Also when using
scripts and copying jars around it's just easy to use the derby*.jar.
It's really no big deal though.
>
[snip]