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