harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: newbie to project-where to start from
Date Thu, 16 Feb 2006 16:14:02 GMT
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.


> 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

> 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)



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message