RE: [SUBMIT] new task for jaxb

[Dominique Devienne <DD...@lgc.com>]

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)).

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,
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

-----Original Message-----
From: Heinz Stüßer [mailto:heinz.stuesser@web.de] 
Sent: Friday, November 29, 2002 12:43 PM
To: Ant Developers List
Subject: Re: [SUBMIT] new task for jaxb

Hi Steve,

in the moment there's no relation, since I wrote my version of the 
jaxb-task without any knowledge of another one.

In principle I think we can merge the two approaches, although they 
follow two quite different ideas. DDs version
uses (as far as I see) a CRC-checksum to determine whether a rebuild is 
necessary while my version is based on timestamps.

EA-support is of course of less significance, since SUN no longer 
supports it - but who knows how many people still want to use it? And
the costs of further supporting it (at least for a while) are quite small.

Heinz


Steve Loughran schrieb:

>Heinz; how does this relate to Dominque D's work in this area? DD? How does
>this relate? Can we merge the two for a best of breed. Also, I think we can
>drop the EA support because that is not going to matter by the time ant1.6
>comes out.
>
>----- Original Message -----
>From: "Heinz Stüßer" <he...@web.de>
>To: <an...@jakarta.apache.org>
>Sent: Thursday, November 28, 2002 11:41
>Subject: [SUBMIT] new task for jaxb
>
>
>  
>
>>Hi,
>>
>>the purpose of the new task I have written is to simplify
>>the usage of Suns JAXB-schema-compiler. At the moment this can
>>be achieved only with a more complicated combination of several
>>tasks.
>>The new task supports both (the deprecated) EA-version and
>>the (actual) beta-version of JAXB.
>>
>>Heinz
>>
>>    
>>
>___________________________________________________________________________
_
>__
>  
>
>>Immer die neuesten ASCII-Bilder versenden, mit WEB.DE FreeMail ist das
>>kein Problem fur Sie. http://freemail.web.de/features/?mc=021170
>>    
>>
>
>
>---------------------------------------------------------------------------
-
>----
>
>
>  
>
>>--
>>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>    
>>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>  
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [SUBMIT] new task for jaxb

[Heinz Stüßer <he...@web.de>]

Hi,

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
build-script.

>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?

Bye

Heinz


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>