You can do excludes with foreach:
<foreach>
<path>
<fileset dir="foo">
<exclude name="**/*.properties" />
</fileset>
<path>
</foreach>
On Wed, Jun 3, 2009 at 2:31 PM, Freeland Abbott <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
