You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Antoine Levy-Lambert <an...@gmx.de> on 2006/06/07 15:47:50 UTC
adding getURL() to Resource [WAS: [Bug 39407] - Change task
to accept the XSLT stylesheet as a resource]
Hi,
XSLT processing, and maybe other tasks would need a method getURL() to be added to Resource.
Any thoughts on that ?
If we do it, do we do :
String() getURL()
or
java.net.URL getURL()
Regards,
Antoine
> -------- Original-Nachricht --------
> Datum: Wed, 7 Jun 2006 13:38:40 +0000 (GMT)
> Von: bugzilla@apache.org
> An: dev@ant.apache.org
> Betreff: DO NOT REPLY [Bug 39407] - Change <xslt> task to accept the XSLT stylesheet as a resource
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39407
>
> Ivan,
>
> thanks for the patch which is now submitted.
>
> I will add a reply to this on the dev mailing list.
>
> Thanks,
>
> Antoine
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: adding getURL() to Resource [WAS: [Bug 39407] - Change
task to accept the XSLT stylesheet as a resource]
Posted by Steve Loughran <st...@apache.org>.
Antoine Levy-Lambert wrote:
> Hi,
>
> XSLT processing, and maybe other tasks would need a method getURL() to be added to Resource.
>
> Any thoughts on that ?
>
> If we do it, do we do :
> String() getURL()
>
> or
>
> java.net.URL getURL()
+1 for this; more strongly typed. Leave the option in for returning null
meaning "unable to make up a URL for this".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Re: adding getURL() to Resource [WAS: [Bug 39407] - Change
task to accept the XSLT stylesheet as a resource]
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hi Matt,
> -------- Original-Nachricht --------
> Datum: Wed, 7 Jun 2006 07:44:43 -0700 (PDT)
> Von: Matt Benson <gu...@yahoo.com>
> An: Ant Developers List <de...@ant.apache.org>
> Betreff: Re: adding getURL() to Resource [WAS: [Bug 39407] - Change <xslt> task to accept the XSLT stylesheet as a resource]
>
> --- Antoine Levy-Lambert <an...@gmx.de> wrote:
>
> > Hi,
> >
> > XSLT processing, and maybe other tasks would need a
> > method getURL() to be added to Resource.
> >
> > Any thoughts on that ?
> >
> > If we do it, do we do :
> > String() getURL()
> >
> > or
> >
> > java.net.URL getURL()
>
> Hmm. I'm not smart enough for this. I guess we
> probably should as file resources have urls. What
> does that say for <url>? Is that a conflict, or is it
> just the most generic of the "real" resource types?
this is not a conflict
> If we make it part of the resource then I would think
> we should use the actual URL type;
OK
> in fact URLResource
> already has this property, so it already implements
> this. This way custom resource implementations could
> create the URL they return with a custom
> URLStreamHandler and the resulting URLs would be able,
> with sufficient JVM permissions set, to behave
> appropriately for whatever resource is declared. How
> does this sound to anyone who cares?
>
I have never dealt with URLStreamHandler(s)
> -Matt
>
My concern is that the system id of stylesheets (or XML documents) which
the <xslt/> task is processing should be set in such a way that entity includes or <xsl:include href=""/> can be resolved properly.
For instance, if we are doing an XSLT transformation with a stylesheet which is defined as a zip resource, for instance the entry org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
from ant-junit.jar, the system id should be set in such a way that if there is in junit-frames.xsl a <xsl:include href="junit-generic.xsl"/> , and junit-generic.xsl is also packaged in ant-junit.jar under org/apache/tools/ant/taskdefs/optional/junit/xsl, the include will be found and used properly.
Same for XML documents having entity includes, or referencing local DTD's or schemas.
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: adding getURL() to Resource [WAS: [Bug 39407] - Change
task to accept the XSLT stylesheet as a resource]
Posted by Steve Loughran <st...@apache.org>.
Matt Benson wrote:
> --- Antoine Levy-Lambert <an...@gmx.de> wrote:
>
>> Hi,
>>
>> XSLT processing, and maybe other tasks would need a
>> method getURL() to be added to Resource.
>>
>> Any thoughts on that ?
>>
>> If we do it, do we do :
>> String() getURL()
>>
>> or
>>
>> java.net.URL getURL()
>
> Hmm. I'm not smart enough for this. I guess we
> probably should as file resources have urls. What
> does that say for <url>? Is that a conflict, or is it
> just the most generic of the "real" resource types?
> If we make it part of the resource then I would think
> we should use the actual URL type; in fact URLResource
> already has this property, so it already implements
> this. This way custom resource implementations could
> create the URL they return with a custom
> URLStreamHandler and the resulting URLs would be able,
> with sufficient JVM permissions set, to behave
> appropriately for whatever resource is declared. How
> does this sound to anyone who cares?
>
ahh, now we are getting complex
Remember that (somehow) even JAR entries can become URLs (see
JarURLConnection)
jar:http://www.foo.com/bar/baz.jar!/COM/foo/Quux.class
Which even gives us insight into jar/zip files.
What we cannot do is trivally add a new tar: url, or the like, primarily
because the URLConnection logic is always implemented in the base
classloader, possibly restricted to extension libraries, I forget. All I
do know is that in some bit of smartfrog I had to add
classpath:some.resource.here URLs and had to make sure that everything
that wanted to load it had to use their own factory stuff.
Things that dont use the custom factory (like, say, Xalan), couldnt
handle custom URLs if they were passed down as strings, embedded into
XSL sheets, etc.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: adding getURL() to Resource [WAS: [Bug 39407] - Change task to accept the XSLT stylesheet as a resource]
Posted by Matt Benson <gu...@yahoo.com>.
--- Antoine Levy-Lambert <an...@gmx.de> wrote:
> Hi,
>
> XSLT processing, and maybe other tasks would need a
> method getURL() to be added to Resource.
>
> Any thoughts on that ?
>
> If we do it, do we do :
> String() getURL()
>
> or
>
> java.net.URL getURL()
Hmm. I'm not smart enough for this. I guess we
probably should as file resources have urls. What
does that say for <url>? Is that a conflict, or is it
just the most generic of the "real" resource types?
If we make it part of the resource then I would think
we should use the actual URL type; in fact URLResource
already has this property, so it already implements
this. This way custom resource implementations could
create the URL they return with a custom
URLStreamHandler and the resulting URLs would be able,
with sufficient JVM permissions set, to behave
appropriately for whatever resource is declared. How
does this sound to anyone who cares?
-Matt
>
> Regards,
>
> Antoine
>
> > -------- Original-Nachricht --------
> > Datum: Wed, 7 Jun 2006 13:38:40 +0000 (GMT)
> > Von: bugzilla@apache.org
> > An: dev@ant.apache.org
> > Betreff: DO NOT REPLY [Bug 39407] - Change <xslt>
> task to accept the XSLT stylesheet as a resource
> >
> >
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=39407
> >
> > Ivan,
> >
> > thanks for the patch which is now submitted.
> >
> > I will add a reply to this on the dev mailing
> list.
> >
> > Thanks,
> >
> > Antoine
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org