Stuart Ballard wrote: > Geir Magnusson Jr <geir <at> pobox.com> writes: >> I think we should certainly be using Muave for testing. However, that >> doesn't remove the need for our own unit tests to be testing >> implementation internals. > > Completely agree. Tests of implementation internals don't belong in Mauve of > course.
Agreed. > I guess the question is whether, when a Harmony contributor wants to write a > test for documented, public, specified API functionality, should that test go > in > Mauve instead of Harmony's own test framework? If the person is a Harmony contributor the test would go into Harmony wouldn't it? If they were a Mauve contributor it would go into Mauve? Of course these are not exclusive options. > Obviously I'd argue that it should, as then it benefits all implementations, > not > just Harmony. How so? what is stopping all implementations running Harmony's Java API tests? > Plus if Harmony contributors are running Mauve regularly, they're > getting the benefits of Mauve tests contributed by developers of other > implementations too. Agreed, and that is a good thing. Since Mauve is under GPLv2 the tests won't end up in our repository tho' and the consequences of combining the tests into a single work have already been discussed. > (I've watched people go down this road before: I was following several > projects > with independent class library implementations years before there was any > prospect of them merging into Classpath as they've now done. Even when there > was > no cooperation on the library code, everybody seemed to agree it was in their > best interests to collaborate on the test suite...) Cool, we accept contributions from everyone who is eligible under the ACQ rules ;-) > If it *is* recommended for Harmony contributors to put such tests into Mauve, > that recommendation probably ought to be mentioned in answer to questions like > the one that I replied to; the original poster didn't say whether their tests > were going to be of implementation internals or not... There are a number of places that people can contribute. If people want their work to be GPLv2 compatible then Mauve is a good choice, if people want their work to be ASL compatible then Harmony is a good choice. I'm not going to suggest where people should contribute their efforts -- in the end it all benefits the open software ecosystem. >> Would you like to help us get it working in our build/test framework? > > I'm afraid you're asking the wrong person: I can't get Mauve working at all... (let's not get into a license discussion again) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
