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:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >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: <mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >> >> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
