On May 12, 2005, at 11:04 AM, Mike Kienenberger wrote:
> (I've cc'd Erik as I'm not sure if he's on the cayenne-devel list,
> and he
> said he was willing to be a resource on ant-related questions.)
I am on the -devel list.
Below are some quick replies without looking at the details of the
build files themselves...
> First off, build-regression.xml seems to be dysfunctional now.
> I'm looking
> into it.
>
> In the process, I noticed that I needed to copy the three hsqldb-
> connection
> setup targets from build-test.xml to build-regression.xml. These
> targets
> initialize properties and set up classpaths.
>
> 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.
> While writing tests for the new classgen stuff , I noticed that
> some of the
> generated test classes have licensing info at the top, and some do
> not.
> This seems like a useful function to provide -- the ability to
> specify a
> licensing string (or some other constant header info) or file to be
> included
> at the top of the generated file.
>
> 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).
> 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.
> 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!
XDoclet has "merge points" that allow this sort of thing. One way to
accomplish this would be to put some strategically placed #parse's in
the file like:
#parse("header.vm")
...
#parse("footer.vm")
Then put empty templates into the template loader path, but allow the
user to place their own path before the built-in loader path. I
could then put all my fragment .vm files into a directory and point
the task to it.
>
> Feel free to just point me to the docs for the ant stuff :)
There's a fair bit of Ant task trivia here:
http://ant.apache.org/manual/develop.html#writingowntask
And of course in Chapter 20 of Java Development with Ant :) (I'll
send you that chapter off-line)
Erik
This archive was generated by hypermail 2.0.0 : Thu May 12 2005 - 11:26:21 EDT