I think it would be more brittle, but perhaps insignificantly so. That is, we'd end up commenting every gwt.jar with "list the last-built/newest one first," and if anyone forgot, you'd get stray builds. But the ant files are pretty stable, so it may not matter.
Isaac's suggestion has me nervous on two fronts, though I'm trying it... first, it's effectively quadratic, because every directory goes into its own <jar> task; excepting alldeps, which could be special-cased, we have at most six elements, so that may be small, except in dev/common.gwt.xml depending on how <fileset> is handled. Second, and perhaps worse, because <foreach> uses a target as its loop body, I'm not sure how to pass down things like manifest contents, destfile, and duplicate flag. The "newest files" variation shouldn't be that hard to write, though, so if we're not going to be happy with either my macro or a resort-of-as-is, I think I might want to just do that "real" fix. On Wed, Jun 3, 2009 at 3:10 PM, Scott Blum <[email protected]> wrote: > One thing we could do: without necessarily modifying gwt.jar right this > second, we could just manually reorder the existing rules such that we list > files known to be newer first. Then if we really care, we could update a > custom ant task later that uses timestamp to choose between identicals. > Would that be better or worse than the track we're on now? > > On Wed, Jun 3, 2009 at 2:13 PM, Freeland Abbott <[email protected]>wrote: > >> Well, I did try to use filesonly first. ;-) >> >> Taking the worst-case example of the "com/" directory entry from a >> hypothetical amalgam of user/build.xml and dev/common.xml's jars, we might >> have up five instances of the "com/" directory being added to a jar (that >> is, sources from src and super, built classes from core and platform, and >> entries from tools jars---maybe lots of those, but they're all old and all >> the same type, so I'll lump them together). With >> duplicate=add|preserve|fail, we can make either the first or last one win, >> but we want the "newest" one to win. >> >> We could, instead of this tack, write our own task, perhaps extending >> ant's JarTask, and do the "most recent" filtering there. That seemed >> heavier than we needed, and the <zipfileset>s an irritating twist to handle, >> but it certainly lets us set the control directly the way we want it, i.e. >> by date instead of lexical order. >> >> >> >> >> On Wed, Jun 3, 2009 at 1:41 PM, Scott Blum <[email protected]> wrote: >> >>> It begins to feel as though we're on the wrong track. :( All we're >>> really trying to solve is jarring things up in a particular order. But in >>> the process, we're defining tags like "sourcefiles" and "artifacts" that >>> seem imbued with meaning. All all this (really) just to solve the issue of >>> adding directory entries. I'm ok with proceeding down this path if there >>> really isn't any more straightfoward way to solve this, but I think we're at >>> a point where it's worth taking a second look high-level. >>> >>> >>> On Wed, Jun 3, 2009 at 1:31 PM, <[email protected]> wrote: >>> >>>> >>>> http://gwt-code-reviews.appspot.com/33837/diff/10/1008 >>>> File common.ant.xml (right): >>>> >>>> http://gwt-code-reviews.appspot.com/33837/diff/10/1008#newcode149 >>>> Line 149: <element name="manifestcontents" optional="true"/> >>>> On 2009/06/03 05:06:18, scottb wrote: >>>> >>>>> Does it not work to just call this "manifest"? >>>>> >>>> >>>> Nope, or at least not that I could find. (That was my first attempt, >>>> actually.) If the macrodef has an element named "manifest," then in the >>>> macro <manifest> means the contents of that user-supplied element (but >>>> not the user-supplied element itself, sadly). And if I use an implicit >>>> element (e.g. "jarelements", such that <manifest> is implicitly a child >>>> of that), I'm only allowed one element total and can't separate >>>> sourcefiles and artifacts, which is the whole point. >>>> >>>> What we could do, though, is to use e.g. "jarelements" as the macrodef >>>> element, and have callers put the jar <manifest> sub-element in that. >>>> So callers would do: >>>> >>>> <gwt.jar> >>>> <artifacts>...</artifacts> >>>> <sourcefiles>...</sourcefiles> >>>> <jarelements> >>>> <manifest>...</manifest> >>>> </jarelements> >>>> </gwt.jar> >>>> >>>> which would allow, not just <manifest>, but also <metainf>, <indexjars>, >>>> <service>... and <fileset>, which makes me nervous, but would at least >>>> have well-defined ordering behind <artifacts/> and <sourcefiles/>. >>>> Would that be better? >>>> >>>> http://gwt-code-reviews.appspot.com/33837/diff/10/1011 >>>> File dev/core/build.xml (right): >>>> >>>> http://gwt-code-reviews.appspot.com/33837/diff/10/1011#newcode27 >>>> Line 27: <sourcefiles> >>>> On 2009/06/03 05:06:18, scottb wrote: >>>> >>>>> <artifacts> seems to make more sense here >>>>> >>>> >>>> Somewhat arbitrary choice, yes, but we want that "artifacts" must be >>>> definitively newer than "sourcefiles." Since the jars here will have >>>> dates as set by svn, and the contents as baked-in to the download files >>>> (as opposed to dates set by ant compilation), I called them sourcefiles. >>>> >>>> But we don't have anything that we build ourselves here, so it doesn't >>>> in the end matter. >>>> >>>> http://gwt-code-reviews.appspot.com/33837/diff/10/1016 >>>> File user/build.xml (right): >>>> >>>> http://gwt-code-reviews.appspot.com/33837/diff/10/1016#newcode82 >>>> Line 82: <zipfileset src="${gwt.tools.lib}/tomcat/servlet-api-2.5.jar" >>>> /> >>>> On 2009/06/03 05:06:18, scottb wrote: >>>> >>>>> Seems like this line and the next two should <artifacts>... does it >>>>> >>>> make a >>>> >>>>> difference, or is my intuition wildly wrong? >>>>> >>>> >>>> Your intuition is mildly wrong. The point of <artifact> is to hint >>>> about what's going to have the newest touch dates, i.e. what's generated >>>> by ant rather than touched from svn. >>>> >>>> Given that these contain org/... classes, the practical impact is small, >>>> but if they were com/... classes, the jars presumably would have >>>> older-than-now dates on the com/ entry (indeed, it's May 2008 for >>>> flute's org/ entry), so making them artifacts could cause spurious >>>> rebuild activity to freshen the directory entries. >>>> >>>> >>>> http://gwt-code-reviews.appspot.com/33837 >>>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
