Discussions

News: APT-Jelly (template-based interface to APT) released

  1. Announcing the release of APT-Jelly 1.0 as an emollient for the abrasive annotation processing procedure established for Sun's Annotation Processing Tool (APT). APT-Jelly leverages the scripting capabilities of Jakarta Commons Jelly to provide a template-oriented interface to APT. This allows developers to use Jelly scripts directly as templates for generating pre-compile artifacts, or to use the scripts to delegate to other template engines (e.g. Velocity).

    APT-Jelly is provided as an alternative to other code-generation engines (e.g. XDoclet) for developers to which to fully leverage Java 5 syntax and features including metadata (annotations), generics and typesafe enums. Furthermore, by using the Annotation Processing Tool to parse and abstract the Java language constructs, APT-Jelly provides compatability also with any future releases, regardless of syntax or structure changes.

    APT-Jelly relieves the developer of a tight coupling between the APT Mirror API and the mechanism used to generate artifacts and it eases the burden of creating and maintaining the artifacts by removing the interaction with a PrintWriter (and the many subsequent calls to println).

    To use a metaphor, APT-Jelly is to the APT engine what JSP is to a Servlet engine.

    For more information, go to http://apt-jelly.sourceforge.net/
  2. I am so disappointed that xdoclet 1 and 2 don't support Java 5 annotations. Cedric Beust's SGen never seemed to catch on. Since the APT will be standardized with Java 6 (JSR-269), this is a great addition. The current APT is really difficult to work with. I'm really hopeful that this will simplify working with the APT and shield us from the details of the current Java 5 Mirror API.

    Thanks a lot!
  3. Announcing the release of APT-Jelly 1.0 as an emollient for the abrasive annotation processing procedure established for Sun's Annotation Processing Tool (APT). APT-Jelly leverages the scripting capabilities of Jakarta Commons Jelly to provide a template-oriented interface to APT. This allows developers to use Jelly scripts directly as templates for generating pre-compile artifacts, or to use the scripts to delegate to other template engines (e.g. Velocity).APT-Jelly is provided as an alternative to other code-generation engines (e.g. XDoclet) for developers to which to fully leverage Java 5 syntax and features including metadata (annotations), generics and typesafe enums. Furthermore, by using the Annotation Processing Tool to parse and abstract the Java language constructs, APT-Jelly provides compatability also with any future releases, regardless of syntax or structure changes.APT-Jelly relieves the developer of a tight coupling between the APT Mirror API and the mechanism used to generate artifacts and it eases the burden of creating and maintaining the artifacts by removing the interaction with a PrintWriter (and the many subsequent calls to println).To use a metaphor, APT-Jelly is to the APT engine what JSP is to a Servlet engine.For more information, go to http://apt-jelly.sourceforge.net/

    Having used Jelly in the past to write some internal Maven 1 plugins, I am not sure this is such a great idea.

    I like the idea of the APT, but Jelly?

    Maven 2 seemed to abandon Jelly in favor of Java.

    I've been writing some code generation lately and have found Velocity up to the task.

    Perhaps, I would use APT-Jelly's Velocity support, but have no desire to do more Jelly development.

    Perhaps Jelly has improved, or perhaps I was using it wrong, but the experience was not very pleasant.

    The way I survived Jelly was by creating Jelly Java tags, and then having the Jelly script delegate most of the Maven plugin to the Java Tag.

    I mostly used Jelly for plugin development, not templating so my experience could be skewed.

    However, the think I like most about Maven 2. I don't need Jelly to write my custom plugins!

    Rick Hightower (linked in),blog
    JSF, Spring, and Hibernate training and consulting
  4. I think you would find that Jelly is actually a nice fit for output (in this case generating code). While I have to admit that I've never actually used Jelly for plugin development, I can imagine how it could be bulky and awkward. Furthermore, in general, I don't believe XML ever works very well as a programming language (or as a script for that matter), and I could point to Ant and XSLT to support that statement. Even though I use both Ant and XSLT regularly with good success, nobody knows better than me that build files and stylesheet transformations can get ugly.

    But in this case, the Jelly script is used as neither a programming language nor a script. It's used as a template. And I think you'll find it works pretty well. Furthermore, as you mentioned, if you don't like to use Jelly as a template engine, use it as a quick script to delegate to a real template engine (e.g. Velocity).

    But you just need to use the APT Mirror API once to see why using Jelly is much better than using the Mirror API (see the background section of the project documentation).
  5. +1

    Didn't James publically apologise for creating Jelly?!

    I've used Groovy and Velocity for code generation in the past and I think Velocity still comes out on top (mainly because it's API has been stable for so long). Its very easy to learn and start working with and there is plugin support for Eclipse for it's templates.

    I've just had another great idea! How about a single API for *all* templating engines! Commons-templating...if only I had time to code-up all these great ideas ;)
  6. Okay, guys, I hear you. I appreciate the feedback. I'll look into putting direct Velocity support into future releases.
  7. Okay, guys, I hear you. I appreciate the feedback. I'll look into putting direct Velocity support into future releases.

    Consider freemarker.
  8. Velocity in/for Jython[ Go to top ]

    I have been using http://airspeed.pythonconsulting.com/ with Jython and it is great.
  9. setters and getters finally?[ Go to top ]

    Is this finally a decent method to generate setters and getters outside a EDI?
  10. Better than APT, IMO, you could (almost incredibly) have Jelly on JAM.

    Off for a sandwich...
    Kit