Erik Hatcher <eri..hatchersolutions.com> wrote:
> > Question #1: Is there any way to share these targets so that we're not
> > maintaining duplicate ant code?
>
> Does the Ant <import> task work for this situation? You can put
> common targets in a separate build file, and <import> it.
Not sure, but I'll take a look!
> > Question #2: Is there an ant element that can produce a string,
> > either from
> > a file or a literal value in the ant.xml? If not, I'd say going
> > with a file
> > is probably the best solution.
>
> What do you mean by produce a string?
>
> If you add a "public void addText(String s)" to your task, it would
> work like this:
>
> <cayenne:cgen map="config/CollexDomainMap.map.xml"
> destDir="${build.dir}/gen"
> superpkg="org.patacriticism.collex.model.cayenne">
> // This is my license header
> </cayenne:gen>
>
> Something like that? Or perhaps with a sub-element for <header>?
> For sub-element support, you would have a "public void Header
> createHeader()" method that returns back a Header Java bean with the
> addText method on it (it could be an inner class).
I was thinking more like
<cayenne:cgen map="config/CollexDomainMap.map.xml"
destDir="${build.dir}/gen"
superpkg="org.patacriticism.collex.model.cayenne">
license="// This is my license header"
or
licensefile="license.txt"
</cayenne:gen>
I know I could do it with two separate attributes, but I was wondering if
there's a common ant element that already handles these kinds of attributes
(file contents or constant string).
> > Third, I'm considering providing a "version", "compiler",
> > "templater", or
> > "target" attribute for class generation along the lines of the
> > "compiler"
> > javac task. "1.1" would be how things are done now (single
> > "classgen").
> > "1.2" would be how I want to redesign things. Any comments or
> > preferences?
> > The default for "version" would be 1.1 for now.
>
> Maybe this could be made into two separate Ant tasks, such that the
> legacy "classgen" one is deprecated? They could share the same base
> class in order to share attributes and such.
What's your reasoning for two tasks rather than one with a switch? One with
a switch allows us to control default behavior while still giving the
advanced user the ability to change behavior.
> > Also, how about the ability to specify a template fragment for
> > inclusion?
> > The primary use case for people other than myself for custom templates
> > appears to be adding additional convenience methods (like primary key
> > support). Rather than having to maintain the entire template, it
> > would
> > probably be easier to just allow an includable fragment that could be
> > inserted at the bottom of the existing template.
>
> That's a good idea!
Yeah, it's easy to add in, which is why I don't mind doing it. :)
#if ($footerAvailable)
#parse ($footer)
#endif
Is there a common use case for supporting more than extra methods at the
bottom?
Anything more than the common case should probably be done by creating new
templates.
> There's a fair bit of Ant task trivia here:
>
> http://ant.apache.org/manual/develop.html#writingowntask
Yeah, I glanced through that a couple days go. For the most part, I don't
have to worry about that stuff as I'm just going to modify the existing cgen
internals rather than create a new task from scratch.
This archive was generated by hypermail 2.0.0 : Thu May 12 2005 - 11:55:39 EDT