You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/04/02 17:26:34 UTC
Using files in classpath in task file=""
A common usage of xslt is to postprocess xml results for documentation,
like in junit, jdepend, etc. The problem is that AFAIK the xslt task
needs a file, not an URL, and hence not a jar resource.
All tasks that resolve files IIUC call
public File resolveFile(File file, String filename)
in FileUtils.java [1]
Again IIUC and AFAIK it could be quite easy to extend this method to use
a url to get the "File". In this way we could use any file fotten from a
URL, and still maintain backward compatibility.
In the future we could even make it optional to use COmmons VFS for it
and have that resolve the URLs and give the streams.
Thoughts?
[1]
http://cvs.apache.org/viewcvs/ant/src/main/org/apache/tools/ant/util/FileUtils.java?rev=HEAD&content-type=text/vnd.viewcvs-markup
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using files in classpath in task file=""
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefan Bodewig wrote, On 08/04/2003 8.49:
> On Fri, 04 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
>
>
>>>* is not as transparent as you say. Tasks could only use the URI
>>>if they first check that the object is is our version of File and
>>>cast to it.
>>
>>No... that's not how it's supposed to be. What other method do they
>>need?
>
>
> You are willing to do more in the File subclass than me.
>
> I thought all you wanted was a way to pass an URI to certain tasks
> where it is not possible to use them right now. Tasks that only
> convert the file name to an URI and pass it up to something else for
> further processing (and this "something else" already knows how to
> deal with different protocols).
>
> Now I understand that you are trying to move to a complete VFS
> abstraction with you innocent looking request ;-)
Yeah :-DDD
These are the filesystem types:
http://jakarta.apache.org/commons/sandbox/vfs/filesystems.html
It's cool that it also has a temporary file system :-)
Here are some enhanced Ant VFS tasks:
http://jakarta.apache.org/commons/sandbox/vfs/anttasks.html
> I'm not sure whether subclassing java.io.File is the best way to do
> this. Does commons-vfs do so?
Nope. Here is the file:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/FileObject.java?rev=HEAD&content-type=text/vnd.viewcvs-markup
Looking at the system, which seems very well thought out, it seems to me
that making Ant use it as the underlying system would really rock the
builds.
Also, it needs most of the tools that Ant has, like bzip and stuff.
From a technological POV putting it under Ant as a VFS makes perfect
sense, but the problem is the usual one: compatibility.
That's why I proposed to reuse io.File, so that we can hook the new
system underneath without touching the tasks.
> Before we invest too much time and
> energy in writing our own layer, we should seriously consider looking
> for existing alternatives.
Definately++
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using files in classpath in task file=""
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 04 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
>> * is not as transparent as you say. Tasks could only use the URI
>> if they first check that the object is is our version of File and
>> cast to it.
>
> No... that's not how it's supposed to be. What other method do they
> need?
You are willing to do more in the File subclass than me.
I thought all you wanted was a way to pass an URI to certain tasks
where it is not possible to use them right now. Tasks that only
convert the file name to an URI and pass it up to something else for
further processing (and this "something else" already knows how to
deal with different protocols).
Now I understand that you are trying to move to a complete VFS
abstraction with you innocent looking request ;-)
I'm not sure whether subclassing java.io.File is the best way to do
this. Does commons-vfs do so? Before we invest too much time and
energy in writing our own layer, we should seriously consider looking
for existing alternatives.
Stefan
Re: Using files in classpath in task file=""
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefan Bodewig wrote, On 04/04/2003 17.55:
> On Fri, 04 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
...
>>Because a URI can be navigated, and it's possible to make a File
>>from a URI.
>
> Not always.
Agreed, not always with the same features. Listing files in a http URL
"dir" is not usually possible for instance.
>> org.apache.tools.vfs.File extends java.io.File
>
> But this version cannot be the argument for the (existing) setters.
> For this to work, IntrospectionHelper will need to take special care
> (i.e. if setXYZ(java.io.File) is found, actually pass it an instance
> of org.apache.tools.vfs.File). This is possible, but ...
>
> * Is this generally desirable?
Yes, this is the question.
> <mkdir dir="http://www.apache.org/"/>
>
> <delete>
> <fileset dir="jar:http://my.server.com/applets/loader.jar">
> <include name="**/*.gif"/>
> </fileset>
> </delete>
>
> means what?
Delete all gif files that are in the jar at
http://my.server.com/applets/loader.jar.
Commons VFS deals with many providers to make this possible, but it's
not always possible, as with http that is generally not writeable.
I would have the same problem if a local file was not writeable, it's
consistent.
> If I sound harsh, please forgive me.
Not at all, don't worry :-)
> I'm trying to show that in some
> situations it may be better to stick with files and we need a way to
> distinguish them.
Yes, I knew that in many cases this was going to happen. But the above
would through an error, as it happens with other non-writeable files.
IIUC the main problem WRT this is that URLs are many times not writeable.
> * is not as transparent as you say.
>
> Tasks could only use the URI if they first check that the object is is
> our version of File and cast to it.
No... that's not how it's supposed to be. What other method do they need?
I can still navigate it, open it, read, sometimes write, all with the
java.io.File signature.
> I.e. the change in
> IntrospectionHelper will only work for tasks that can handle it.
Are you sure?
> Both points mean that it becomes hard to explain when URIs can get
> used and when not.
>
> Just as people have by now become so used to the relazive path
> resolution magic that happens inside Ant that they now report it as a
> bug if a ceratin attribute is not resolved relative to basedir, we
> will get bug reports that certain tasks do not deal with URLs of
> protocol foo properly. I find it hard to imagine that we'll be able
> to convert all tasks that could reasonably be expected to deal with
> URIs in one go.
That again I would agree with. I believe that this solution can work
*only* if we do not need to change the tasks *at all*. If we need to
change the tasks, better using a new attribute.
>>if I gave you just an url in the constructor, you could write
>>almost, if not all, those methods.
>
> That really depends on the protocol you use. delete() for resources
> loaded from a jar located on a remote server, loaded via some P2P
> protocol? I may be making up things, I know.
Yes, I know, but getting real:
1) is that a real use case
2) what makes it not possible or sensible to signal it's not featured?
>>Am I really missing the obvious? Could as well be.
>
> Same here.
I think we are nailing it now :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using files in classpath in task file=""
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 04 Apr 2003, Costin Manolache <cm...@yahoo.com> wrote:
> Not sure if IH can deal with overloaded methods
In a hacky way, as always.
It already does so. If it finds two attribute setters of the same
name and one takes a String argument, it will favor the other one.
Stefan
Re: Using files in classpath in task file=""
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote, On 07/04/2003 9.11:
>
...
> After the replies and a bit of thought, maybe even setXYZUrl(URL) is not
> the right solution.
>
> We have a FTP task, a get task, etc... putting the URL as a parameter
> short-circuits the process of getting stuff and using it, and
> potentially makes Ant dwonload files at every run without devs knowing.
>
> So, AFA I'm concerned, I would need a styleResource="" parameter, *or*
> overloading the file attribute *just* to get stuff from jars. That is,
> if the filename starts with resource:// or something like that, get the
> file as a resource.
>
> What should I send a patch for?
Further note: I need this "getting from resources" in xslt and import
tasks.
Please advise WRT the easiest and most consistent solution.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using files in classpath in task file=""
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 08 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
> IIUC style="" would accept only files, so using it I'd have to be
> sure it's on the FS.
Yes. With the additional benefit over
> styleuri="" instead can be used both for remote and local files, if
> I resolve it to a URL, and later with the VFS.
that style="foo/bar" is going to resolve foo/bar relative to the
project's basedir while styleuri="foo/bar" is going to pass the string
literally.
Stefan
Re: Using files in classpath in task file=""
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefan Bodewig wrote, On 08/04/2003 10.23:
> On Tue, 08 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
>
>>Stefan Bodewig wrote, On 08/04/2003 9.07:
>>
>>>But why stick with the resource protocol? Can't Xalan deal with
>>>stylesheets loaded via http?
>>
>>Please excuse me, I'm a PITA,
>
> I knew that before this thread ;-)
Be careful, I take it as a compliment ;->
>>You mean use a full URL?
>
> Actually, we are talking about URIs which don't have to be URLs.
>
> Java's URL class isn't able to deal with opaque URIs AFAIK. (opaque
> are those URIs that don't start with a / after the scheme in layman's
> terms, like mailto:bodewig@apache.org).
>
> So I'd probably simply take a String argument and pass that along,
> without even looking at it.
ahhh
>>Would that not confuse and create problems when we do move to a VFS?
>
> Why?
If the urls used now are not consistent with the later-used VFS uris.
But probably it's a moot point.
>> <xslt in="a" out="b" style-url="the/url/to/the/style"/>
>
> Be careful with the dash in the attribute's name.
hehehe, xslt uses it, why is it so evil? ;->
> I mean
>
> <xslt in="a" out="b" style="the/url/to/the/style"/>
>
> for files that need to be resolved and
From javadocs:
"If it is null, this call is equivalent to
new java.io.File(filename)"
And java.io.File does not have a constructot that takes a URL, so it
would be:
<xslt in="a" out="b" style="the/pathname/to/the/style"/>
> <xslt in="a" out="b" styleuri="http://xml.apache.org/some-style.xsl"/>
>
> for a stylesheet obtained from the web.
Ok.
> This implies that build file
> writers have to know whether a style sheets comes from the filesystem
> or not. Is this a problem?
Nope.
IIUC style="" would accept only files, so using it I'd have to be sure
it's on the FS.
styleuri="" instead can be used both for remote and local files, if I
resolve it to a URL, and later with the VFS.
Can this do?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using files in classpath in task file=""
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 08 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
> Stefan Bodewig wrote, On 08/04/2003 9.07:
>
>> But why stick with the resource protocol? Can't Xalan deal with
>> stylesheets loaded via http?
>
> Please excuse me, I'm a PITA,
I knew that before this thread ;-)
> You mean use a full URL?
Actually, we are talking about URIs which don't have to be URLs.
Java's URL class isn't able to deal with opaque URIs AFAIK. (opaque
are those URIs that don't start with a / after the scheme in layman's
terms, like mailto:bodewig@apache.org).
So I'd probably simply take a String argument and pass that along,
without even looking at it.
> Would that not confuse and create problems when we do move to a VFS?
Why?
> <xslt in="a" out="b" style-url="the/url/to/the/style"/>
Be careful with the dash in the attribute's name.
I mean
<xslt in="a" out="b" style="the/url/to/the/style"/>
for files that need to be resolved and
<xslt in="a" out="b" styleuri="http://xml.apache.org/some-style.xsl"/>
for a stylesheet obtained from the web. This implies that build file
writers have to know whether a style sheets comes from the filesystem
or not. Is this a problem?
Stefan
Re: Using files in classpath in task file=""
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefan Bodewig wrote, On 08/04/2003 9.07:
> On Mon, 07 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
>
>
>>What should I send a patch for?
>
>
> For now, new attributes would be better IMHO.
Yes. Solution to the problem, and extra goodies later.
> But why stick with the
> resource protocol? Can't Xalan deal with stylesheets loaded via http?
Please excuse me, I'm a PITA, but with all these mails I got a bit lost B-)
You mean use a full URL? Would that not confuse and create problems when
we do move to a VFS?
So you mean:
<xslt in="a" out="b" style-url="the/url/to/the/style"/>
?
And
<import url=""/>
?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using files in classpath in task file=""
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 07 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
> What should I send a patch for?
For now, new attributes would be better IMHO. But why stick with the
resource protocol? Can't Xalan deal with stylesheets loaded via http?
Stefan
Re: Using files in classpath in task file=""
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote, On 04/04/2003 19.57:
...
>
> However we can do it incrementally. Adding an setXYZUrl(URL) attribute
> should work - without the overloaded method problems.
>
> Well - it can be just setXYZUrl( String ). All we need is to add the
> attributes to the tasks where it is needed.
>
> Should we add it to <copy> ? I don't know :-) But XSLT is a good candidate.
After the replies and a bit of thought, maybe even setXYZUrl(URL) is not
the right solution.
We have a FTP task, a get task, etc... putting the URL as a parameter
short-circuits the process of getting stuff and using it, and
potentially makes Ant dwonload files at every run without devs knowing.
So, AFA I'm concerned, I would need a styleResource="" parameter, *or*
overloading the file attribute *just* to get stuff from jars. That is,
if the filename starts with resource:// or something like that, get the
file as a resource.
What should I send a patch for?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using files in classpath in task file=""
Posted by Costin Manolache <cm...@yahoo.com>.
Stefan Bodewig wrote:
>> org.apache.tools.vfs.File extends java.io.File
>
> But this version cannot be the argument for the (existing) setters.
> For this to work, IntrospectionHelper will need to take special care
> (i.e. if setXYZ(java.io.File) is found, actually pass it an instance
> of org.apache.tools.vfs.File). This is possible, but ...
It is a bit hacky, you're right. A cleaner solution would be to add
setXYX( java.net.URL ) for tasks that can deal with URLs, and
make this works ( i.e. IntrospectionHelper can deal with it ).
Not sure if IH can deal with overloaded methods - and how it can
distinguish if a String should be converted to File or URL.
> * Is this generally desirable?
>
> <mkdir dir="http://www.apache.org/"/>
I think this would be better handled by some webDAV antlib.
I agree, blindly turning file to URL is not the best solution.
> protocol foo properly. I find it hard to imagine that we'll be able
> to convert all tasks that could reasonably be expected to deal with
> URIs in one go.
However we can do it incrementally. Adding an setXYZUrl(URL) attribute
should work - without the overloaded method problems.
Well - it can be just setXYZUrl( String ). All we need is to add the
attributes to the tasks where it is needed.
Should we add it to <copy> ? I don't know :-) But XSLT is a good candidate.
Costin
Re: Using files in classpath in task file=""
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 04 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
> Sure. Look at the JDK 1.4 version,
Ahh, far to modern for Ant.
> Because a URI can be navigated, and it's possible to make a File
> from a URI.
Not always.
> org.apache.tools.vfs.File extends java.io.File
But this version cannot be the argument for the (existing) setters.
For this to work, IntrospectionHelper will need to take special care
(i.e. if setXYZ(java.io.File) is found, actually pass it an instance
of org.apache.tools.vfs.File). This is possible, but ...
* Is this generally desirable?
<mkdir dir="http://www.apache.org/"/>
<delete>
<fileset dir="jar:http://my.server.com/applets/loader.jar">
<include name="**/*.gif"/>
</fileset>
</delete>
means what?
If I sound harsh, please forgive me. I'm trying to show that in some
situations it may be better to stick with files and we need a way to
distinguish them.
* is not as transparent as you say.
Tasks could only use the URI if they first check that the object is is
our version of File and cast to it. I.e. the change in
IntrospectionHelper will only work for tasks that can handle it.
Both points mean that it becomes hard to explain when URIs can get
used and when not.
Just as people have by now become so used to the relazive path
resolution magic that happens inside Ant that they now report it as a
bug if a ceratin attribute is not resolved relative to basedir, we
will get bug reports that certain tasks do not deal with URLs of
protocol foo properly. I find it hard to imagine that we'll be able
to convert all tasks that could reasonably be expected to deal with
URIs in one go.
> if I gave you just an url in the constructor, you could write
> almost, if not all, those methods.
That really depends on the protocol you use. delete() for resources
loaded from a jar located on a remote server, loaded via some P2P
protocol? I may be making up things, I know.
> Am I really missing the obvious? Could as well be.
Same here.
Stefan
Re: Using files in classpath in task file=""
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefan Bodewig wrote, On 04/04/2003 17.21:
> On Fri, 04 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
>
>
>>What I mean is not to change the passing of a File object. I mean
>>that we can *wrap* an URL in a File. So we pass a File, and use an
>>URL, getting a Virtual File System.
>
> How so - put the URI into the name and abuse File as a String? I'd
> really like to understand that.
>
> We are talking about java.io.File here 8-)
Sure. Look at the JDK 1.4 version, it has this constructor:
public File(URI uri)
Why? Because a URI can be navigated, and it's possible to make a File
from a URI.
We could do:
org.apache.tools.vfs.File extends java.io.File
and make
public File(String URI)
that also can accept a URI to create itself.
Look at all the methods of java.io.File: if I gave you just an url in
the constructor, you could write almost, if not all, those methods.
So, if we make the method in the utils return a File that is in reality
a org.apache.tools.vfs.File but still used as a File, we could make all
tasks that use a file be able to accept an url.
url string
-> in utils it's made into a org.apache.tools.vfs.File
-> it's given as a java.io.File
-> it's used as a java.io.File, but the methods inside use the "VFS"
Am I really missing the obvious? Could as well be.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using files in classpath in task file=""
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 04 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
> What I mean is not to change the passing of a File object. I mean
> that we can *wrap* an URL in a File. So we pass a File, and use an
> URL, getting a Virtual File System.
How so - put the URI into the name and abuse File as a String? I'd
really like to understand that.
We are talking about java.io.File here 8-)
Stefan
Re: Using files in classpath in task file=""
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefan Bodewig wrote, On 03/04/2003 8.17:
> On Wed, 02 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
>
>
>>If I had it in jars I could ship it automatically with the jar that
>>has the task that generated index.xml, so I can easily do something
>>like:
>>
>> <xslt in="index.xml" out="index.html"
>> style="resource:/a/style.xsl"/>
>
>
> I see. What I don't see is how we could use an URI here without
> breaking backwards compatibility.
>
> In XSLTProcess we get the style parameter via setStyle(File), this
> obviously cannot be called with anything else but a file object. If
> we wanted general URIs, we'd have to change the signature and break
> custom tasks that inherit from or delegate to instances of
> XSLTProcess. No way.
>
> I'd rather propose to add an alternative attribute styleURI or
> something to XSLTProcess.
What I mean is not to change the passing of a File object.
I mean that we can *wrap* an URL in a File. So we pass a File, and use
an URL, getting a Virtual File System.
A File is used to open a connection, and to navigate the URI space, and
a URL has the same features.
>>Be able to specify a URL for every task that needs a file, and that
>>thus uses the above fileutils method.
>
> Again, not without changing the tasks to use something else, not File,
> in their setter method and thus severely breaking backwards
> compatibility.
But if we still use File?
>>Or maybe KISS and just add a getStyleResource(String
>>styleResource). It solves the immediate issue and doesn't open other
>>potential problems.
>
> Seems the better way to me - at least until we are prepared to break
> API compatibility on almost all tasks at once 8-)
If it were to break like this, I would also oppose. But could the
"wrapping" ba a viable solution that easily gets us full URL usage in
all file-accepting tasks?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using files in classpath in task file=""
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 02 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
> If I had it in jars I could ship it automatically with the jar that
> has the task that generated index.xml, so I can easily do something
> like:
>
> <xslt in="index.xml" out="index.html"
> style="resource:/a/style.xsl"/>
I see. What I don't see is how we could use an URI here without
breaking backwards compatibility.
In XSLTProcess we get the style parameter via setStyle(File), this
obviously cannot be called with anything else but a file object. If
we wanted general URIs, we'd have to change the signature and break
custom tasks that inherit from or delegate to instances of
XSLTProcess. No way.
I'd rather propose to add an alternative attribute styleURI or
something to XSLTProcess.
> Be able to specify a URL for every task that needs a file, and that
> thus uses the above fileutils method.
Again, not without changing the tasks to use something else, not File,
in their setter method and thus severely breaking backwards
compatibility.
> Or maybe KISS and just add a getStyleResource(String
> styleResource). It solves the immediate issue and doesn't open other
> potential problems.
Seems the better way to me - at least until we are prepared to break
API compatibility on almost all tasks at once 8-)
Stefan
Re: Using files in classpath in task file=""
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefan Bodewig wrote, On 02/04/2003 17.34:
> On Wed, 02 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
>
>>The problem is that AFAIK the xslt task needs a file, not an URL,
>>and hence not a jar resource.
>
> Errm, where does it need the file?
Sorry, I'm not clear.
Code:
<xslt in="index.xml" out="index.html" style="style.xsl"/>
ATM IIUC I need style.xsl in the filesystem; I cannot directly use the
one that's in the classpath directly.
If I had it in jars I could ship it automatically with the jar that has
the task that generated index.xml, so I can easily do something like:
<xslt in="index.xml" out="index.html" style="resource:/a/style.xsl"/>
>>All tasks that resolve files IIUC call
>>
>> public File resolveFile(File file, String filename)
>>
>>in FileUtils.java [1]
>
> Most of them implicitly by defining setXYZ(File) setters, yes.
>
>>Again IIUC and AFAIK it could be quite easy to extend this method to
>>use a url to get the "File".
>
> Return an URL? Receive an URL? I don't understand what you want.
Be able to specify a URL for every task that needs a file, and that thus
uses the above fileutils method.
In this way I could do for example:
<ant antfile="http://url/to/buildfile/"/>
<xslt in="index.xml" out="index.html" style="jar:/style.xsl"/>
etc
Yes, I could simply add a getStyleResource(String styleResource) to the
task, but it would not make this change available to all tasks that use
the above method.
Or maybe KISS and just add a getStyleResource(String styleResource). It
solves the immediate issue and doesn't open other potential problems.
What do you think? I hope I was clearer this time =8-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using files in classpath in task file=""
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 02 Apr 2003, Nicola Ken Barozzi <ni...@apache.org> wrote:
> The problem is that AFAIK the xslt task needs a file, not an URL,
> and hence not a jar resource.
Errm, where does it need the file?
> All tasks that resolve files IIUC call
>
> public File resolveFile(File file, String filename)
>
> in FileUtils.java [1]
Most of them implicitly by defining setXYZ(File) setters, yes.
> Again IIUC and AFAIK it could be quite easy to extend this method to
> use a url to get the "File".
Return an URL? Receive an URL? I don't understand what you want.
Stefan