Martin responded right away - so here's more bugzilla correspondence.
Note I cave right away on design issues. It is their code, after all, and Martin's suggestions make it easier for me to get something done and into the code base quicker.

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

------- Additional Comment #9 From Martin Aeschlimann 2005-09-21 05:49

[reply] ------- Hi John, thanks for you comment! Here are my responses:
I don't see where we would break any clients or tests when using
${type_declaration}, So I would head for that, it's the simplest solution for
the user (no changes).
The only thing that changes is that everybody that used the new file pattern
should know that we now have an extra template for the type declaration. As
said, that will take its time.
The idea of using variables like ${superclass_constructors} doesn't work, in my
opinion. First, NewTypeWizardPage.constructTypeStub is an API method and we
currently give all clients the full freedom to create whatever they want in the
type body. Second, there many ways to categorizing methods, static methods,
public/private methods, getter/setters, fields.. Some of the categories overlap,
so it will be hard to write a template that is still correct. Then, when
creating methods you also have to create imports. Imports depend on the context
where the type is used. Textual templates are not powerful enough here.
So if you are fine with 'I'll copy/paste my methods in the catrogies later' then
we should go with that. From comment 7 I see that there are other use cases for
this template, so it would be great to have the new template.
If you have a more convenient API for getCompilationUnitContent API, please make
a suggestion. We just have to keep the old API areound and compatible. But no
problem to add an extra, more convenient variant. To be honest, I don't really
see how things can be made much simpler. There's a certain number of parameters
that have to be passed, and I found it simpler to more API with less parameters,
having smaller blocks of funtionality, increasing the flexibility how you can
use the various parts. E.g. we have functionality that just needs a type comment
(Add Javadoc action), some functionality doesn't want comments (pass a single
'null').

------- Additional Comment #10 From John Kaplan 2005-09-21 15:26
[reply] ------- Martin - OK - good enough. I can move ahead based on your suggestions. If we
don't provide any new template variables to direct eclipse where to put
methods, it simplifies the problem quite a bit. To my mind, it removes the
need to change the existing APIs.
I am still uneasy about introducing more model functionality (especially
template reading and resolving code) into NewTypeWizardPage, but will proceed
with the target of changing as little of the existing code as possible. I'll
try first to create a StubUtility/CodeGeneration routine to read the new user
template for the type content, then call that and evaluate the template in a
new body for NewTypeWizardPage.constructTypeStub.
I'll let you guys know how that works one way or the other.
- John

------- Additional Comment #11 From John Kaplan 2005-09-22 00:20
[reply] ------- (In reply to comment #7)
> The discussed changes will also fix the common template complaint of wanting
> to add default members for logging and versioning.
Matt - thanks for the comment, and the vote. I'll put in a test case that has
a default member variable to be sure this works.

- - - - - - - - -

So next post, I will get right to coding and testing...