[jdt-dev] JDT/JUnit Improvements

[David Green <dgreen@xxxxxxxxxxxxx>]

My company is about to start a rather ambitious multi-year project
creating a set of Eclipse plugins to support full programming support
(syntax highlighting/refactoring/run/debug/etc) of our business
programming language, as well as as a large set of tools used by
customers to configure our products. We have already implemented our own
IDE for this purpose from scratch, which supports all of the features
written above, but are moving in the direction of replacing it with
Eclipse.

Unfortunately, we've run into some difficulties with JDT/JUnit. We're
working to fix these issues in our local repository (maintaining current
code style and best practices of the Eclipse foundation), but are hoping
to be able to contribute them back so we don't have to maintain them in
a separate repository in the long-term.

Some of the issues we're having are:

* org.eclipse.jdt.junit's inability to split the console output down by
test. When you're running a suite with 10,000 tests, the console view
becomes pretty much unusable.

* Lack of default launch configuration settings (i.e. default vm
arguments) per launch config, and the misnamed "Default VM Arguments" in
the Installed JREs preferences page... It's not a set of VM defaults...
Because defaults would be overridable in the individual launches if they
are truly just defaults. In our experimentation, these "default"
arguments are *always* sent to the VM, and worse, there's no hint of
their existence in the launch config dialog.

* Inability to have automatically-created launch configs get
reused/cleaned up. Once again, when you have tens of thousands of tests,
and you're launching method-based, class-based, and suite-based JUnit
runs all day using "Run As...", you end up with hundreds of these, which
must be manually removed.

We already have 2 full-time developers working on our Eclipse efforts,
and that will probably scale to 5 or 6 in the next month. We're happy to
send patches, or commit to a separate branch or whatever the usual
procedure is. I'd also like to discuss each change with jdt-dev before
implementation, to ensure that we code it in a way that will maximize
it's chances of being accepted into the production codebase.

David Green
Guidewire Software
http://www.guidewire.com