I unsuccessfully try to expand the scope again...

When I was running my tests, I realized something about my new solution that I didn't like. It is this: a user will go to the preferences window and check a checkbox that says "enable assertions for JUnit tests." Then the user will rerun a JUnit test that already has a launch configuration setup, and assertions will not be enabled. That's because the code only enables assertions on new launch configurations as they are created, not on existing launch configurations.

So, I started looking into what it would take to enable or disable unit tests for all existing launch configurations when the checkbox is OK'ed. This turns out to be a fair pain-in-the-butt. You have to read all the launch configurations, filter the ones that are JUnit or JUnit plug-in tests (OK, that part's not so hard) but then you have to dig through all their JVM arguments and match the ones that enable assertions to see if they are already enabled or not. Since I don't know very well the constraints and variations among VMs on entering these args, I'm not confident I can detect them and frame their beginnings and endings in all cases. So I start implementing it, hoping I can work through the issue. But alsoI sense I am expanding the scope of my solution in a possibly controversial way, so I send off an e-mail to Markus explaining my dilemma.

- - - - - - - - - -

Markus - I have a preliminary solution done that adds a checkbox to the
JUnitPreferencesPage, uses that to set a preference, and then uses the
preference to default new JUnitLaunchConfiguration objects to have their VM
args defaulted to blank or to the enable assertions argument. It all works, and
I have an automated test for the page and the preference, but not yet the
launch configurations.

I ran into something, however, that seems like a bug in this solution. When you
set the preference, it only signals the system to add the VM arg to
subsequently created launch configurations. All the old launch configurations
are still sitting without the VM arg. So it seems to the user they just enabled
assertions, but when they rerun a unit test, assertions still aren't enabled
(and vice-versa with disabling).

So, I figured I should go through all the JUnitLaunchConfiguration objects, and
re-sync their arguments to however the user set this preference. I'm working my
way through the code of this, and almost have something to try.

Thought I should bring this up to you for comment before I spring the whole
thing on you at once. Will have a complete patch soon.
- John

- - - - - - - - - -

As I might have guessed Markus wants none of this idea, and writes back with a simplifying change instead.

- - - - - - - - - -

We should not fiddle around with the user's exisiting launch configurations.
The user may have set up some launch configurations with -ea and some without.
If the checkbox would change all existing configs, that would destroy the
user's configuration and would not allow him to enable -ea for new tests
without destroying his work.

You should rather call the checkbox 'Enable assertions for new JUnit launch
configurations' to avoid any confusion.

- - - - - - - - - -

As usual, I cave in immediately and get on with the fix. I changed the text, and commented out my half-implemented configuration-surfing-parsing-and-changing code. (You never know when you may need it later...)

- - - - - - - - - -

OK - I can see that - it's definitely the safer way to go.

I was almost done with the code to do it too - the only part I was having a
hard time with was how to reliably take an argument out of the VM args - I
imagine that's even worse from your perspective.

So, the only part I have left to do to finish is to figure out how to call the
right things programatically to create new launch configurations through
JUnitLaunchShortcut, JUnitTabGroup, and AbstractPDELaunchConfigurationTabGroup,
and then I can finish the automated tests.

- - - - - - - - - -

Next, the patch and the wait....