I actually did this a few years ago mainly as a learning exercise in freemarker, but also because I was hacking the tools templates at the time and velocity was annoying me.

It was a few years ago so apologies for the ensuing vagueness.

Implementing the FreemarkerRenderer was pretty much a 30 minute exercise (due to the abstraction). I seem to recall that I had an issue with implementing the 'two-pass' method used by the velocity renderer. IIRC the two-pass was used to identify dependencies for the import block which was rendered on the second pass.

The hard part was of course the templates. The vm->ftl conversion tool actually did about 90% of work, a few regexps and maybe a bit of manual tinkering did the rest. I only ported the templates for the module I was needing to hack (might have been pojos or ejbs i cant recall) and my end 'solution' called both the velocity and freemarker renderers.

I was actually in the process of cleaning it up and sending it to you guys when I lost it all (including at least of month of production work) to a disk crash (IBM DeathStar GXP45). That reminds me I better go backup now...

I expect that tools is pretty dramatically different now so Im not sure how relevant my experience was. But I have to say hacking the freemarker templates was a joy compared to the drudgery of velocity. The power of freemarker could facilitate a total refactoring of the templates and an orders-of-magnitude increase in hackability/maintainability.

Personally I have piggybacked on tools to generate other boilerplate code specific to my project needs. If this process can enhanced/abstracted/formalised/documented etc I see that a big plus to the value of hibernate tools. (think spring/seam/tapestry)

The problem with velocity logging is that it thinks everything is a warning - which it definitly is not. Impossible to filter down to a sensible level (and some of the logging is usefull)

But again, I have done my work on making it less verbose in its logging but it does not solve my main problem namely that exceptions and spellingerrors are ignored.

FYI I started doing the freemarker conversion today (just to see if I could do it within reason and to uncover any hidden limits/annoyances within freemarker) and I must say that FreeMarker looks *very* sweet compared to velocity. It is sooo freaking simple to figure out what template is failing and why - in velocity I have to basically guess and use hrs to debug it (and each time I add in extra guards if possible into the tools code so futures users won't bump into them)....in FreeMarker it is all seem to be built in.

...and sure lets do a AJAX based tools ;) (actually semi-serious, since a ajax query console would be nice ;)

It took 1,5 day to convert it from velocity to freemaker and it is now available in cvs in hibernateext/tools in the TOOLS_FREEMARKER branch.

The porting experience were a bliss compared to velocity development and I removed alot of "doublecheck-velocity" code, found bugs ignored by velocity and life were great (i'll blog about it when i get around to it), but i did find one thing that were pretty annoying with freemarker.

It apparently has to be hard to escape e.g. ${build.dir} and #{msg.${some.property}} and such strings occurs pretty often in build.xml's and jsp/jsf pages.

The best thing i've found until now is: ${'#'}{msg.${some.property}} but that actually get pretty ugly in a file with many $ or #'s.

But this is the *only* downside I have found ....the rest is just upsides.

If anyone have the courage and time then I would appreciate if you tried to make these new templates crash! The code passes all 145 unittests, but i'm sure you have some weird usecase that i did not catch ;)

REMEMBER: This is currently *only* for the hibernateext/tools part - meaning only Ant, not eclipse. (eclipse probably just work, but i haven't tested it yet)

Never used freemarker for ant build files, but experience tells me that writing a macro will clean the escaping up for you. The macro might be as ugly as hell (see above) but your core templates (ie. what yours users see) will be cleaner.

Of course you can also apply DRY priciples and create 'components' using macros; they can call other macros, do callbacks to java code etc. The end result is your templates look a lot more like your target files. (I use freemarker to generate C/C++/Java/SQL code :o)

Will try and have a look at the branch this weekend to give you some feedback.

The problem with velocity logging is that it thinks everything is a warning

Did find the verbosity of logging annoying yet helpful and necessary last time i used tools (reveng).

Yes, but the verbosity is horrible and you only needed it because velocity would not let me fail early so i could tell you exactly what was causing the problem....i guess that is why they bumped all the levels up to insane high levels so it always were visible in the velocity logs...but damn that is bad!

Quote:

Never used freemarker for ant build files, but experience tells me that writing a macro will clean the escaping up for you. The macro might be as ugly as hell (see above) but your core templates (ie. what yours users see) will be cleaner.

Of course you can also apply DRY priciples and create 'components' using macros; they can call other macros, do callbacks to java code etc. The end result is your templates look a lot more like your target files. (I use freemarker to generate C/C++/Java/SQL code :o)

yes, with freemarker we can definitly write more compact and modular templates.

[quoteWill try and have a look at the branch this weekend to give you some feedback.[/quote]

be warned though - i haven't comed all the templates for visual "layout" the automatic conversion did not do everything beautifull. But the functionallity should be exactly the same.