From ant-dev-return-40045-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org Mon Dec 02 16:33:18 2002 Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 57756 invoked from network); 2 Dec 2002 16:33:17 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Dec 2002 16:33:17 -0000 Received: (qmail 18702 invoked by uid 97); 2 Dec 2002 16:34:13 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 18622 invoked by uid 97); 2 Dec 2002 16:34:12 -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 18545 invoked by uid 98); 2 Dec 2002 16:34:11 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: From: Dominique Devienne To: "'Ant Developers List'" Subject: RE: [SUBMIT] new task for jaxb Date: Mon, 2 Dec 2002 10:33:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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)). 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!=20 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=FC=DFer [mailto:heinz.stuesser@web.de]=20 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=20 jaxb-task without any knowledge of another one. In principle I think we can merge the two approaches, although they=20 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=20 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=FC=DFer" >To: >Sent: Thursday, November 28, 2002 11:41 >Subject: [SUBMIT] new task for jaxb > > > =20 > >>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 >> >> =20 >> >_______________________________________________________________________= ____ _ >__ > =20 > >>Immer die neuesten ASCII-Bilder versenden, mit WEB.DE FreeMail ist = das >>kein Problem fur Sie. http://freemail.web.de/features/?mc=3D021170 >> =20 >> > > >-----------------------------------------------------------------------= ---- - >---- > > > =20 > >>-- >>To unsubscribe, e-mail: = >>For additional commands, e-mail: = >> =20 >> > > >-- >To unsubscribe, e-mail: = >For additional commands, e-mail: = > > > =20 > -- To unsubscribe, e-mail: = For additional commands, e-mail: = -- To unsubscribe, e-mail: For additional commands, e-mail: