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
