Classpath / Mauve integration

[Stephen Crawley <crawley at dstc dot edu dot au>]

Hi Graydon,

This is a response to two of your recent emails to 'classpath' and
'mauve-discuss' respectively.

in a 'mauve-discuss' email, graydon@redhat.com said:
> the next logical step in my mind -- is whether to start merging mauve
> into classpath so it configures and builds "naturally" as part of the
> day-to-day development cycle on classpath (using the classpath build
> dir, compiler and VM selection, for example, and running as the
> nominal "make check" for classpath). I'm wondering how taboo an idea
> that is, whether anyone would mind if I had a go at it.

I'm not sure I understand how you propose to do this 'merge', but here
are some (IMO) no-nos.

  1)  Don't merge the Mauve source tree into the Classpath source tree.
      [I don't think you intended to but ...]

  2)  Don't make the Mauve config environment dependent on Classpath.
      If the Mauve config environment is 'aware' of Classpath, it should
      also work if Classpath isn't there.
      
  3)  Don't make the Classpath config/build environment dependent on Mauve.
      If the Classpath config/build environment is 'aware' of Classpath, 
      it should also work if Mauve isn't there.
      
I also have doubts as to whether adding a 'make check' to Classpath will
work for most VMs that use Classpath.  In many cases, Classpath does not
currently 'know' anything about the 'client' VM; e.g. Kissme & SableVM.

In the case of Kissme, Mauve integration works as follows.  The Kissme
autoconf setup has some magic to find the Classpath sandbox and
(optionally) the Mauve sandboxes.  The locations of these sandboxes are
then expanded into the relevant Makefiles and scripts.  Targets are
provided in the Kissme makefile to configure Mauve for Kissme testing,
and to run a regression tests using the Kissme VM.  All of this is done
without modifying either the Mauve or Classpath source trees to be aware
of Kissme.

In a 'classpath' email, graydon@redhat.com said:
> my gut feeling (I don't mean to be insulting or dismissive, just
> observing) is that few people -- and progressively fewer as time
> passes -- will have a use for mauve outside testing classpath. if
> they're a proprietary vendor, they'll buy a sun compatibility kit;
> everyone else seems, from my limited perspective, to be slowly coming
> around to the benefits of just throwing their weight behind classpath.

It depends on what you mean by "have a use for mauve outside testing
classpath".  I use Mauve to test Kissme, but I do this "outside of
Classpath" in the sense that I run the tests from the Kissme build
environment.  [See above.]

More generally, testing against Mauve should be relevant to all Java
implementors, whether or not they use the Sun JCK testsuite.  While
Mauve and the JCK tests do largely overlap, there will inevitably be
Mauve testcases that cover aspects that JCK testcases don't cover.
Compatibility of Java implementations in these aspects is of interest to
Java developers, even if vendors don't care.  Hence, there is a clear
case for keeping Mauve largely independent of Classpath.

-- Steve