Martin responds again with more work for me...

- - - - - - - - - - - -

Hi John,
with 'late' I meant it was late after having all the discussion already and you
already having a patch. Time wise we are fine M3 is not so soon.
I think I would favour that approach, mostly for the consistency reason.
Thanks for the patch!
Having the CU, you can't conclude the type name. The user might create an inner
type. So I think, method getTypeBody needs an additional parameter String typeName.
I'm not sure if the new line in the template would do a difference as the body
will be reformatted and the settings in the formatter will be used. I think that
the best solution anyway.
I'll apply the patch and fix the remaining issues (type name). Thanks a lot!

- - - - - - - - - -

John, another idea: I think it would be good to have different templates for
class, interface, enum and annotation. Do you want to add that? Otherwise I can
add the change.
From the API standpoint I would add an extra 'int kind' flag, using new constants.

- - - - - - - - - -

This opened up a couple of cans of worms. First of all, there was the additional work of adding the 4 new templates. Second, doing any more work meant I had to face the fact that I hadn't figured out how to sync to Eclipse. I definitely wanted to make the change, though, it was a good idea that I had considered myself, and I wanted to do as much as I could to finish the contribution. Without thinking too much about it, I wrote back with what I thought I would have to do to make the change, and asked for advice as to how to sync.

- - - - - - - - - -

Martin - I would be glad to do the change adding different 'kinds' of templates. I was thinking of that myself, but thought it was too big a change to suggest before you guys had accepted my first change. Just to get it straight - this means 4 code templates in the Window->Preferences->(etc) dialog, and the 'int kind' enum that NewTypeWizardPage passes through to StubUtility will select the proper template?
New Java class body
New Java interface body
New Java enumeration body
New Java annotation body

How about instead of an enum, the "NewxxxWizard" classes pass the ID of the template down to StubUtility directly instead of requiring a lookup based on an enum? This way the Wizard classes don't have to refer to an enum defined in StubUtility, and it saves us the lookup.

One more thing - what's the best way to pick up your Eclipse changes and the checked in version? Should I wait for the next integ or is it safe to just pick up the head versions of the affected few files? I just haven't figured out what to sync to in CVS, so I'm using the last integ build and wiping it out and starting over each version. I haven't done any really iterative development yet.

Thanks,- John

- - - - - - - - - - -

Martin wrote right back.

- - - - - - - - - - -

You can take HEAD, but sometimes also you need some referenced plugins in HEAD.
Follow the jdt-ui dev mailing list for messages about what other plugins are
needed in HEAD until the next I-build. It happens from time to time that we
forget to write this on the mailing list, but here are the candidates:

org.eclipse.core.filebuffers
org.eclipse.jdt.core
org.eclipse.jface.text
org.eclipse.ltk.core.refactoring
org.eclipse.ltk.ui.refactoring
org.eclipse.text
org.eclipse.ui.editors
org.eclipse.ui.workbench.texteditor

Sure the kind constants can be the template keys (good idea), but you have to
check them before using them (throw an illegal argument exception otherwise)!

- - - - - - - - - - -

OK - so far so good, a little encouragement and a new thing to try with the syncing. So next time I delve into the code and try to see how to fit my new changes in....