ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Heinz Stüßer <>
Subject Re: [SUBMIT] new task for jaxb
Date Sun, 15 Dec 2002 11:25:07 GMT

Dominique Devienne wrote:

>This design goal of my task was to (1) avoid rebuilds when not necessary,
>and to (2) always force a rebuild in case something could be out of date.
>I also do not enforce any policy on where schema files can be located, and
>simply take a fileset of schemas. I also assume (which Jaxb beta-1 also
>does) that each schema is generated in its own directory, which is inferred
>from the schema location, possibly with the use of a mapper.
>A cursory look at Heinz's task showed me he used <uptodate> and <dependset>
>to achieve (1), which uses timestamps. I discarded this technique (which I
>also used when I prototyped my task in XML) since it either doesn't detect
>target files removed, or forces to know before hand what are supposed to be
>all the target files (thus failing (2)).
that's not completly correct. Indeed my version doesn't detect if a 
generated file is removed -
but is this a real problem? If it is  we have the same problem in the 
javac-task, which doesn't
recompile if someone removes the class-file belonging to a inner class. 
And using wildcards in
<dependset> frees from explictly knowing all target-files.

But the real advantage of DD's version - from my point of view - is the 
usage of the <mapper>,
which allows to bundle the handling of multiple  schemas in one target, 
thus simplyfing the

>When I did was to a posteriori record what the Jaxb compiler generated, by
>takes a listing of all files produced, along with their timestamp. Next time
>the task runs, it checks the timestamp of the schema vs. all the generated
>files (achieve goal (1)) to know whether it needs to re-generate (fully,
>since I delete the target directory completely). It also re-records the
>status of the generated files, and compares it to the recorded status using
>a CRC check on the status files (which for this implementation are simply
>properties files/instances. Easier than using a full fledge XML status file
>implementation-wise). The advantage of this approach is that it will trigger
>a re-generation if any target file is modified *and* removed (and it fast
>enough). Will also trigger a re-generate if people start adding files in the
>target directory, which I like as a feature as well (they have no business
>doing so!).
>I think I'll eventually abstract this status check thing in its own class,
>when I refactor my Jaxb task, maybe adding proper XML persistence of the
>status file (the impl using properties is a bit of a hack).
>Heinz task as the merit of being properly unit tested, when mine is not,
+ documented and integrated into the source-tree ;-)

>although it's used in a production build under CruiseControl, so I'll know
>quickly if I break something ;-) I know, that's not a good excuse! 
>In short, I think I prefer my task, but what else do you expect from the
>task writer ;-) I also don't care about EA support.
>Cheers, --DD
The decisive question is - how do we proceed to integrate a jaxb-task 
into ant?



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

View raw message