Could you build the jar incrementally using <uptodate> to update with newer/missing files from each source directory?
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 -~----------~----~----~----~------~----~------~--~---
