The last couple of days I’ve been trying to see how easy I can
make it to work on GNU
Classpath from inside Eclipse. Since the big merge in
libgcj, working directly on Classpath has become the preferred mode of
development, at least for most ordinary library changes.

To this end, first I updated the Eclipse build infrastructure in
Classpath. This had rotted a little from disuse; I had to update the
java build paths a little. While I was there I also added a build
rule to ensure that some generated java files were created, and to
ensure that the native code was built (at the moment it is set up so
that the native code is only built when something in that directory is
modified — a nice feature I didn’t know Eclipse had).

Next I turned Mauve
into an Eclipse project. It depends on having a classpath project in
the same workspace and uses the just-built GNU Classpath as the
bootclasspath to build against.

So, at the moment, you can try this out very easily:

• Fire up Eclipse 3.1
• Check out GNU Classpath and wait for it to build
• Check out Mauve and wait for it to build
• Hack away

For best results, you will also want to install the ChangeLog plugin and the
Bugzilla plugin.

I think there are two logical next steps. First, we convince
Robert to put JamVM into
cvs (right now you can only download the tar files) and set it up as
an Eclipse project. Second, we add a JamVM dependency to Mauve and
make some shared launch configurations to run the test suite.

With these two changes in place, working on Classpath will be
pretty easy. You will then be able to run the test suite and see any
failures at the touch of a button (or, likewise, run the visual tester
against the just-built Classpath). With a little scripting we can
have it show just regressions.

This would be a good stopping point. However, there are a couple
of Eclipse plugins that we could write — and that hopefully someone
will volunteer to write — that would make life even simpler.

We could have a plugin which understands Mauve. For instance it
could scan the sources to determine what tests are available, and
provide a tree view so that the developer could select what subset of
tests to run. Also, it could automatically track test results, show
regressions in a nice way, and perhaps provide a way to jump directly
from a regression to either the test case or the corresponding class
in Classpath.

Another idea is to have a plugin that understands japi files. It would
work a bit like the FindBugs plugin and would
immediately flag API bugs as errors while you type. I think this
could essentially eliminate a class of (occasional) bugs.

If you wanted to get super-crazy you could write a plugin to make
a patch, massage the ChangeLog entry into shape, and then compose and
send a note to classpath-patches. This basically the final frontier
in integrating Classpath’s (somewhat antiquated, I suppose) processes
into the IDE.

I know! Eclipse.org or the FSF should sponsor their own SoC. And
put me in charge!

Other Eclipse News

The Eclipse world is pretty huge, I don’t really follow it all. I
did think the new Eclipse/XUL project
sounded interesting though. I like to hear about ways that Eclipse
can integrate or even simply interoperate with different parts of the
open source platforms. (Note that the URL has “sex” in it, so odds
are that you can’t visit it from the machines in your public library
🙂