Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 71417 invoked from network); 15 Dec 2002 11:25:04 -0000 Received: from exchange.sun.com (HELO nagoya.betaversion.org) (192.18.33.10) by daedalus.apache.org with SMTP; 15 Dec 2002 11:25:04 -0000 Received: (qmail 3791 invoked by uid 97); 15 Dec 2002 11:26:23 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 3775 invoked by uid 97); 15 Dec 2002 11:26:23 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 3763 invoked by uid 98); 15 Dec 2002 11:26:22 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DFC6693.2070207@web.de> Date: Sun, 15 Dec 2002 12:25:07 +0100 From: =?ISO-8859-1?Q?Heinz_St=FC=DFer?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: de, en MIME-Version: 1.0 To: Ant Developers List Subject: Re: [SUBMIT] new task for jaxb References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 and >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 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 , 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: For additional commands, e-mail: