velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Collignon <>
Subject Re: XmlGen Ant Task
Date Thu, 20 Sep 2007 18:50:30 GMT
Nathan Bubna wrote:
> The documentation for this looks great! How does this compare to
> other xml-generation/transformation Velocity projects (namely DVSL and
> Anakia).  Not that there isn't room for more, there always is; i'm
> just curious how you think it compares.
Here is how I would compare them. (  I do not know the other 
implementations in details
so if I forget some features just tell me ..)

About Process  :
   One XML + One Velocity Template (vsl) => Generated Code
   It is designed to create XML transformations a bit like XSLT

   One Velocity Template (dvsl) applied to a set of XML files => Generated Code
   It is designed to create XML transformations a bit like XSLT

   text property files + velocity template => Generated Code

   Multiple XML files (or file fragments with XPath) + velocity template =>
   Generated Code
   Extension of Texen.  It is more designed to generate code with 
   properties coming from XML files than XML files transformations.

About XML Nodes access :
Anakia :
  Using jdom API ( element.getChildren(), element.getAttributeValue("attName"))
  Using xpath with velocity handler (I suppose) :
  Walking in the jdom tree with : $treeWalk.allElements($element

  Write transformation rules like in XSLT 
  (#match("document") , $context.applyTemplates()
  Using dom4j API

  No access to XML files, only property files supported

  Using syntax like "library.books" of ""
  Using XPath expression[@genre='comic']
  Using DOM API on elements

> If it's a large codebase or is intended to be a separate project (as
> opposed to an enhancement to an existing project), then it would have
> to go through the incubator:
It does a good job but is not really a large codebase ...just 3 classes !-)

> If it could be refactored to be just a patch(es) to enhance Texen,
> then i think you would just need to open a JIRA issue and attach the
> files there.  Of course, then there's the question of eventually
> getting you commit access so that you can work on it directly, so we
> don't always have to commit your patches for you.  For that to happen,
> we'd want to see evidence that you'll stick around (not just dump code
> once and disappear) and help out on the mailing lists.  So, more than
> anything it's a matter of seeing comittment over time (we're talking
> months, not weeks).  The reason for the high standard is that
> abandoned code becomes a weight on the rest of the project(s) and that
> commit access to one Velocity project means access to all of them.
That might be possible.  Not only Texen code would have to be patched 
but also the documentation.

XmlGen is at the beginning, for now it fits my needs but I am sure they 
might be some other
feature requests ..  I am ready to make it improved and give some 
support.  Regularly but not
more than 1h a week. 
> In any case, you should definitely announce your project on these
> lists (as you've done), add some links to it on the wiki (like the
> PoweredBy page and anywhere else that seems relevant), and generally
> promote connection between XmlGen and Velocity.
I  go there a leave a word about it !

Thanks for your answer


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message