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
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 thi
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 us
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 Xal
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. Wh
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
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
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
> nee
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 A
.
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.
loca
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
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.
]
> 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, s
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 pos
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
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 U
d 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
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
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
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 i
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 fil
23 matches
Mail list logo
