ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: String -> Ressource (was Re: archivefileset resources)
Date Fri, 23 Mar 2007 14:18:41 GMT

--- Stefan Bodewig <> wrote:

> On Wed, 21 Mar 2007, Matt Benson
> <> wrote:
> > I think what is needed is a well-known syntax
> specification for
> > specifying a string representation of
> [resource-type][String to pass
> > to constructor] e.g. "file?/foo/bar.baz",
> > "url?", "string?blah blah
> blah".
> This is so I can say
> <unzip
> instead of
> <unzip>
>   <url
> </unzip>
> right?

Yes; additionally, and more usefully perhaps:

<echo output="file?foo">foo</echo>
as a replacement for
<echo file="foo">foo</echo>

In general I suppose I have always seen this concept
as being most useful for specifying output either with
tasks' attributes/properties or with mappers.  Then
again, anyplace the resource could be specified in
this inline fashion suggests higher ease-of-use;
overriding a property from the command line could use
an entirely different resource as source, destination,
etc. for a given operation.

> Sounds right.
> > One may recall this as something I've been after
> for awhile--I
> > consider it the "next step" for resource handling
> in Ant.  For code
> > compartmentalization we could probably add the
> code to generate a
> > Resource from a String to ResourceUtils, but IH
> would know how to
> > use e.g. RU.getResource(Project, String) to set
> Resource attributes
> I guess we'd need something dynamic, i.e. there has
> to be a way to
> register a ressource prefix with RU so that I can
> have string
> representations for my own ressource types.

I had assumed we could specify things in such a way as
to specify the resource type simply by its typedef,
but I suppose a shortcoming of doing it this way is
that for types from antlibs they must be explicitly
typedef'd or have their ns mapped.  Well, I suppose

wouldn't be the end of the world, and of course


would be the preferred way of doing this; also having
the long form available would mean one could add an
antlib with -lib, set a property with the long form,
and now custom resources from a given antlib can be
injected into a build that has no knowledge
of/dependency on that antlib.  Weird.  :)

> >  (for BC, FileResource would be the default).
> For BC we'd have to keep the File-argument setters
> anyway.  IH could
> be changed to use setSrc(Ressource) in favor of
> setSrc(File) and use
> the later if no ressource mapping was found.  No
> real need to have a
> default in RU.  OTOH it might be convenient for
> users when they can
> simply omit the "file?" prefix for files.

That'd be quite a bit of IH modification to make it
preserve > 1 type for a given property.  I can't
decide what would be the best all-around solution, but
it does seem that if we overloaded the same property
setters with File and Resource, it might be easiest
overall to add explicit code that setSrc(File) won't
override setSrc(Resource) in IH (maybe no type can
override a Resource), then default to FileResources as
planned.  Otherwise IH will have to have its internals
changed quite a bit to maintain knowledge of multiple
potential property types.

> > This is to all intents and purposes the only way,
> IMHO, to seriously
> > take advantage in Ant tasks of our early decision
> to design
> > getOutputStream() into the Resource contract. 
> You'll notice my use
> > of the "?" character above to indicate the
> preceding text was the
> > name of a currently available type.  I used "?"
> because for xmlns as
> > well as fs reasons I'm pretty sure this character
> should NOT be a
> > colon.
> I agree that a colon would be a bad choice, at least
> if we allow file
> ressources to be specified without a prefix.  I
> don't really see any
> conflict with xmlns.

This goes back to my idea of simply using the
registered type name to denote the resource desired,
hence the conflict with xmlns if a user were to use a
custom resource in a namespaced antlib.  :)

> > However I'm not sure what the RIGHT "trigger
> character" is and IMO
> > this is the only outstanding question stopping us
> from adding this
> > feature to Ant.
> bikeshedding? 8-)

I get those little allegories mixed up.  Is that the
one where we can blab back and forth forever, but
ultimately whoever is doing the work can make the

> "?" isn't pretty but works for me.  "@" would
> probably work nicely
> (file@/usr/local/bin/xemacs) but may get unwieldy if
> you use constant
> ressource specifications inside of macrodefs (you'd
> have to double the
> "@").  No obvious choice IMHO, I'd take whatever you
> pick.

Agreed wrt @.

> > Aside from allowing IH to transform a String into
> a given Resource,
> > you'll see that tasks using mappers can choose to
> pass the mapped
> > names to this same factory code and work with
> resources, or they can
> > behave as normal and they will break if a user
> tries to map to an
> > arbitrary resource type
> Sounds good.
> > (assuming its string representation can't be
> misinterpreted as a
> > file, a situation I hope we'll be able to prevent
> esp. by choosing
> > the right "trigger character").
> There won't be any such character.  AFAIK the only
> forbidden character
> in Unix filenames is a / and this obviously is a
> very bad choice for
> the "trigger".  "?" and "*" are unlikely in
> filenames, but both are
> used as wildcards in patterns - now that you mention
> using the string
> representation in mappers:
>    <globmapper from="file?*.xml"
> to="url?http://home/*.html"/>
> Here the "?" might look ambiguos.

Actually, globmapper doesn't seem to support ?.  ;) 
Also, remember that mapping would ordinarily be
undertaken by passing in getName(), e.g. the part of a
filename beyond the basedir.  So ordinarily the full
resource representation wouldn't include the resource
type and all.  Really mappers are kind of kludgy as
they require a lot of implicit knowledge on how to use
them--I'm pretty sure there are places in Ant that use
mappers slightly differently anyway.  :|

> OK, what is left?  "#", "="?  Or
> "url("?

I kind of liked the parentheses thing when I saw it...
I wonder if it looks too much like a method call.


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

The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.

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

View raw message