Re: Using files in classpath in task file=""
On Tue, 08 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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=""
Stefan Bodewig wrote, On 08/04/2003 10.23: On Tue, 08 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]). 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. Be careful with the dash in the attribute's name. hehehe, xslt uses it, why is it so evil? ;-> I mean 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: 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Using files in classpath in task file=""
On Tue, 08 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]). 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? > Be careful with the dash in the attribute's name. I mean for files that need to be resolved and 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=""
Stefan Bodewig wrote, On 08/04/2003 9.07: On Mon, 07 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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: ? And ? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Using files in classpath in task file=""
Stefan Bodewig wrote, On 08/04/2003 8.49: On Fri, 04 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Using files in classpath in task file=""
On Mon, 07 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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=""
On Fri, 04 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> 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=""
On Fri, 04 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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=""
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: Using files in classpath in task file=""
Pick the name you think it is more appropriate.
Some thoughts:
Alternatively, we could have something more general that you can pass a URI
and knows how to use it, but alternatively if the value if that of a file, then
it construct a URI for it.
As long as we get the expected behavior I do not mind.
Jose Alberto
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 07 April 2003 08:38
> To: [EMAIL PROTECTED]
> Subject: Re: Using files in classpath in task file=""
>
>
> On Fri, 4 Apr 2003, Jose Alberto Fernandez <[EMAIL PROTECTED]>
> wrote:
>
> > I would like for ANT to do this for me, transparently.
> >
> >
> >
> > or somethig like that.
>
> Sure, should be trivial using FileUtils#toURI together with
> setLocationURL(File), I'm just not sure about the attribute name.
> locationURL would imply that its value was an URL and not a location
> that gets turned into an URI - at least to me.
>
> Hmm, uriOfLocation="${myfile}"? uriForLocation?
>
> Attributes are case-insensitive in Ant.
>
> Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: Using files in classpath in task file=""
On Fri, 4 Apr 2003, Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> I would like for ANT to do this for me, transparently.
>
>
>
> or somethig like that.
Sure, should be trivial using FileUtils#toURI together with
setLocationURL(File), I'm just not sure about the attribute name.
locationURL would imply that its value was an URL and not a location
that gets turned into an URI - at least to me.
Hmm, uriOfLocation="${myfile}"? uriForLocation?
Attributes are case-insensitive in Ant.
Stefan
Re: Using files in classpath in task file=""
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 ? 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Using files in classpath in task file=""
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? > > 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 ? I don't know :-) But XSLT is a good candidate. Costin
RE: Using files in classpath in task file=""
On a related subject, one problem I have found is that there is no portable way right now in ANT to obtain the URL of a file: Currently we would do something like: but the number of "//"s is diferent for UNIX(2) and Windows(3), and you have to do some nasty conditioning. I would like for ANT to do this for me, transparently. or somethig like that. You need this for passing file parameters to Jose Alberto > -Original Message- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: 03 April 2003 07:18 > To: [EMAIL PROTECTED] > Subject: Re: Using files in classpath in task file="" > > > On Wed, 02 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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: > > > >> 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 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Using files in classpath in task file=""
Stefan Bodewig wrote, On 04/04/2003 17.55: On Fri, 04 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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. http://www.apache.org/"/> http://my.server.com/applets/loader.jar";> 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Using files in classpath in task file=""
On Fri, 04 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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? http://www.apache.org/"/> http://my.server.com/applets/loader.jar";> 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=""
Stefan Bodewig wrote, On 04/04/2003 17.21: On Fri, 04 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: Using files in classpath in task file=""
OK, me too I wish Ant was using more URLs instead of files... Using my little resource: custom URL protocol, I could then easily reference any resource in $ANT_HOME/lib. Right now though, you can turn around the current limitations but first doing a of the URL you want (and with resource: URLs, you can get resources too), and then use it as a file. Not ideal, but would work in most cases. What would be useful then if facilities within Ant to easily deal with the temporary files created, so that there's clean up automatically for example once the build terminates. As Stefan pointed out, making Ant use URLs instead of File in many tasks would be a major backward-incompatible undertaking. --DD -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 9:22 AM To: [EMAIL PROTECTED] Subject: Re: Using files in classpath in task file="" On Fri, 04 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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=""
On Fri, 04 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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=""
Stefan Bodewig wrote, On 03/04/2003 8.17: On Wed, 02 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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: 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Using files in classpath in task file=""
On Wed, 02 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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: > >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=""
Stefan Bodewig wrote, On 02/04/2003 17.34: On Wed, 02 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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: 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: 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: http://url/to/buildfile/"/> 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Using files in classpath in task file=""
On Wed, 02 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> 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
