Potentially, yes... that would make building the jar a longer operation (several updates, not one pass), but would ensure that the newest thing was in place at the end of the first cycle, which is what we want.
But I think ant-contrib's <foreach>, operates on <path>s, which I think precludes exclusion (e.g. of **/*.properties, which we do from src because they've been filtered into bin). So we'd probably still end up writing some custom Ant task code... On Wed, Jun 3, 2009 at 2:21 PM, Isaac Truett <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
