> My dream :
> <xslt in="somedata.xml" out="someresult.html"
styleresource="zip:file:foo/bar/my.zip!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="${resource:foo.zip!/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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
