Currently I do a large amount of java code generation at work. We use Velocity
as the engine for the generation. All we did was write a simple java wrapper
around it.

In the last few days, I have started playing with Hibernate and had (a very
quick) look at the (java) code generation program.
Here are some of the ideas for the next version:

* Use velocity and templates. Most organizations have their own java standards.
Generated files need headers, javadoc, adhere to company code standards,
etc. With templates, you can easily change them to suite your needs.

* Use a two layered approach. Generate an (abstract) base object (which
never gets changed) and a subclass object (which gets extended with business
logic). This allows easy regeneration while preserving custom changes. One
simple way of integrating this into the development process is for the generator
to check to see if a file is read-only. If it is, it gets replaced. That
way, generated files get replaced and custom files are preserved.

* Separate parser, data and template. The generator should be split into
a parser which parses the xml and builds up a data model. This is then placed
in the context and merged into the template. This separation allows for
easy modification and extension of the generator.

* Allow use plugins. Velocity can use any java class as a generation tool.
This allows users to extend templates very easily. For example, you can
register a tool as follows:
$pluginUtil.addPlugin("myplugin","au.com....MyPlugin")
and then call a method on it as follows:
$myplugin.convertString("AaAaAa")
You can also get the tools to manipulate the data model.

* Use ant to start the generator (either as a task or as a target). This
solves many classpath problems, etc and removes the need for (ugly) .bat
files.

* Create a clean data model. For example, instead of generating imports
on the fly, create a list of imports and store the in a list. Then the template
designer can simply iterate thru them. They can sort them, replace them,
add to them, etc.  

* texen seems a good starting point for a generator (see velocity web
site)

* Uses may want to implement hashcode, equals, toString, etc in their
own way and with their own rules. Templates and a simple data model allow
them to do this.

* Using existing software reduces the maintenance costs, increases the
development skill base, and speeds up development.

* You also get logiing, event listeners, etc when generating (all for
free)

Let me know what you think about the above ideas.

Gavin

Most of these ideas are good, and I and Max and others have discussed similar things before.

However, there is quite a lot of work there.

If you want to implement something like this, you are very welcome.

Hello,

I have started playing around with the code and refactoring it. I will keep you posted. I was wondering what work is being done at the moment (as I do not want to duplicate effort).

Cheers

I would love to see this one, but it has been hold back since it requires quite a bit of work to keep up with the core hibernate model - at a period Gavin was putting in new golden features every day.....so until I (or someone else) found a way/time to find a method to keep the codegenerator's model uptodate with features nothing is happening in this area :(

The main problem is to find a good model that can embrace the need for a codegenerator as opposed to the hibernate core. I would e.g. love to use the hibernate parser (or a variant of) it that could run in non-reflection mode so we would could keep the two parsing "modes" easily in sync.

Hello all,
I have a very basic velocity renderer.
It's a kind of hack of hbm2java.
didier

Please submit a patch ;)

What does this look like and where would I find it?

It is part of the hibernatext - only available in cvs at the moment.
net\sf\hibernate\tool\hbm2java\Hbm2JavaTask

Just use standard ant way of including it in your build files
<hbm2java config="xxx-config.xml">
<classpath ...>

<fileset ...>
</hbm2java>

Just the way you should expect - i think ;)

/max