ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject Re: Resources & Introspection
Date Mon, 24 Apr 2006 21:03:11 GMT
> > My dream :
> > <xslt in="somedata.xml" out="someresult.html"
> styleresource="zip:file:foo/bar/!alpha/beta/style.xml"/>
> >
> No! It was my dream first and you can't have it! :)  I
> agree wholeheartedly.  IIRC myself, Stefan, and
> probably others took part in a discussion of this
> nature some time ago... though I'm too frustrated by
> my slow home internet connection to find the thread
> ATM.  Maybe we can get some momentum behind this.  I
> think the simplest approach would be to default to
> file; but let the colon-delimited prefix represent a
> defined type in the project, e.g. file, url... and
> look it up.  At the time I believe I was able to
> convince Stefan that this belonged in
> IntrospectionHelper; sounds like you agree.

Hmmm, the proposed syntax looks very much like a URL, no? So why not
let the URL parsing code do all the work? The JDK code that does that
is supposed to follow the appropriate standard for this parsing, no
need to re-invent something that would have be to documented, no? a
URL is implicitly a Resource, isn't it? Are there Resource types which
are not URLs? To support any Resource type, even user-defined ones, to
be created from a plain string, you'd need to re-invent all the stuff
done in URL.

So my vote would be for Antoine's styleresource attribute to take a
URL, no? Of course there's the issue of where to resolve local paths
from? For URLs, it's normally the "directory" the XML (or HTML)
document was found in (i.e. it's parent URL), which kinda conflicts
with Ant's basedir philosophy.

FWIW, I used to install a custom resource: URL protocol before
<import> came along, so I could modularize my builds with entity
includes, but without having hard-coded paths. Once it's set, you can
find "files" (resources in the JDK sense) on the classpath anywhere,
and you get free parsing from the URL framework. The trick is to
install the URL though. Needs to be done as JVM startup, or needs a
custom URL factory I think (I always used the former).

BTW, Something which might be useful to use Resources in legacy tasks
accepting only File attributes would be a PropertyHelper that creates
a temp file from the resource (with proper timestamp copied from the
resource), with the deleteOnExit flag. So we could say <xslt
style="${!/ant/bar.xsl}" ... />. Error reporting might
suffer from such an approach though. A task (<get>?) could also do the
same, but would then need to expose an attribute name. Then again, it
would allow to remove the file right away after the transform.

Anyways, I'm rambling and might have strayed from the point ;-) --DD

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

View raw message