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.
property name=fileurl locationURL=${myfile}/
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=
Pick the name you think it is more appropriate.
Some thoughts:
property name=x uriOfFile=${fileName}/
property name=x valueAsUri=${fileName}/
property name=x locationAsUri=${fileName}/
property name=x uriForLocation=${fileName}/
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.
property name=x uri=${fileName}/
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.
property name=fileurl locationURL=${myfile}/
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=
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=
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: 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 [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: 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=
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 get 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: 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=
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. 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
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:
property name=fileloc location=${myfile}/
property name=fileurl value=file://${fileloc}/
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.
property name=fileurl locationURL=${myfile}/
or somethig like that. You need this for passing file parameters to
xslt/
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:
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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? 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=
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: 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
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=HEADcontent-type=text/vnd.viewcvs-markup -- 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
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: 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
