ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: XmlProperty (was Re: XmlProperty, AntUnit, questions)
Date Wed, 02 Nov 2005 15:56:24 GMT
--- Stefan Bodewig <> wrote:

> On Tue, 1 Nov 2005, Matt Benson
> <> wrote:
> > Since in the case of this task a single resource
> is wanted as input
> > it doesn't seem right to accept a whole resource
> collection,
> > although I suppose that is one option.
> I used resource collections in similar situations
> for the archive of
> tarfileset, the nested resource of gzipresource or
> the inout to the
> bunzip2 task for example.  I can easily imagine
> situations where you
> want a collection that contains exactly one
> resource.  Say you have
> two files as options and want to select one of them
> based on a
> property or the OS or whatever.  So I'm all for
> supporting single
> resources by means of a resource collection and a
> check at runtime,
> that asserts the size of the collection.
That is one way; I'm not sure if we're on the same
page below:

> > This leads me to an issue I've been waiting to
> present for some
> > time: does Ant >= 1.7 need a mechanism for
> specifying a specifically
> > typed resource from a String, and accompanying
> modifications to
> > IntrospectionHelper to... help with the
> introspection? :) e.g.:
> > 
> > file:foo
> > url:
> > property:foo
> In this case, make the <url> resource accept a
> nested resource and
> validate it is a proper URL for the first two and
> use ${foo} in the
> third.

To make sure we understand each other, what I mean
here is to allow e.g.:
<copy resource="url:someurl" tofile="foo" />
or something similar, IH would pass "url:someurl" to a
ResourceHelper class or some such that would attempt
to locate a Resource type defined as "url" and call a
String constructor with "someurl".

This is more useful for specifying resources for
output than for input.  Remember we made the decision
to support getOutputStream() on Resource, and
ResourceUtils contains the means to copy one to the
other.  So the use of FileNameMappers could be
extended such that resources could be mapped, if we
devise a means of deducing a resource from a string,
most likely falling back to FileResource if no match
is found for BC...

This has been another of my
so-odd-as-to-likely-be-unpopular ideas,

> Stefan
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Yahoo! Mail - PC Magazine Editors' Choice 2005

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message