You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2007/03/23 06:30:06 UTC
String -> Ressource (was Re: archivefileset resources)
On Wed, 21 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> I think what is needed is a well-known syntax specification for
> specifying a string representation of [resource-type][String to pass
> to constructor] e.g. "file?/foo/bar.baz",
> "url?http://www.apache.org", "string?blah blah blah".
This is so I can say
<unzip
src="url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
instead of
<unzip>
<url url="http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
</unzip>
right?
Sounds right.
> One may recall this as something I've been after for awhile--I
> consider it the "next step" for resource handling in Ant. For code
> compartmentalization we could probably add the code to generate a
> Resource from a String to ResourceUtils, but IH would know how to
> use e.g. RU.getResource(Project, String) to set Resource attributes
I guess we'd need something dynamic, i.e. there has to be a way to
register a ressource prefix with RU so that I can have string
representations for my own ressource types.
> (for BC, FileResource would be the default).
For BC we'd have to keep the File-argument setters anyway. IH could
be changed to use setSrc(Ressource) in favor of setSrc(File) and use
the later if no ressource mapping was found. No real need to have a
default in RU. OTOH it might be convenient for users when they can
simply omit the "file?" prefix for files.
> This is to all intents and purposes the only way, IMHO, to seriously
> take advantage in Ant tasks of our early decision to design
> getOutputStream() into the Resource contract. You'll notice my use
> of the "?" character above to indicate the preceding text was the
> name of a currently available type. I used "?" because for xmlns as
> well as fs reasons I'm pretty sure this character should NOT be a
> colon.
I agree that a colon would be a bad choice, at least if we allow file
ressources to be specified without a prefix. I don't really see any
conflict with xmlns.
> However I'm not sure what the RIGHT "trigger character" is and IMO
> this is the only outstanding question stopping us from adding this
> feature to Ant.
bikeshedding? 8-)
"?" isn't pretty but works for me. "@" would probably work nicely
(file@/usr/local/bin/xemacs) but may get unwieldy if you use constant
ressource specifications inside of macrodefs (you'd have to double the
"@"). No obvious choice IMHO, I'd take whatever you pick.
> Aside from allowing IH to transform a String into a given Resource,
> you'll see that tasks using mappers can choose to pass the mapped
> names to this same factory code and work with resources, or they can
> behave as normal and they will break if a user tries to map to an
> arbitrary resource type
Sounds good.
> (assuming its string representation can't be misinterpreted as a
> file, a situation I hope we'll be able to prevent esp. by choosing
> the right "trigger character").
There won't be any such character. AFAIK the only forbidden character
in Unix filenames is a / and this obviously is a very bad choice for
the "trigger". "?" and "*" are unlikely in filenames, but both are
used as wildcards in patterns - now that you mention using the string
representation in mappers:
<globmapper from="file?*.xml" to="url?http://home/*.html"/>
Here the "?" might look ambiguos.
OK, what is left? "#", "="? Or "url(http://www.apache.org/)"?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource (was Re: archivefileset resources)
Posted by Dominique Devienne <dd...@gmail.com>.
> > --- Steve Loughran <st...@apache.org> wrote:
> rule 1 of xml: nobody understands XML namespaces
> rule 2: anybody who says they do. still doesnt.
>
> so there are the following categories
>
> -ignorant of xmlns
> -vaguely aware, but doesnt understand
> -think they understand, but doesnt really
> -knows xmlns enough to know it doesnt make sense, and doesnt understand
Maybe I'm being naive Steve, but the rules for XML NS are *NOT* that complex.
It's fairly easy to know which NS an element or attribute belongs to,
and the parser tells you anyway.
> if you meet someone who thinks they do understand it, ask them if, in
> xml schema, the ##local namespace is in ##other, or not.
How namespaces are used in XSDs for validations is not really part of XML NS.
Here's my limited understanding of XML NS which is enough to know AFAIK:
1) attributes are in no namespace, unless they have an explicit
namespace prefix, which of course must have been declared and be in
scope.
2) elements with an explicit namespace prefix, which of course must
have been declared and be in scope, belong to that explicit namespace.
Sure, the prefix can be remapped to another namespace anywhere in the
document, but people rarely do that, and the parser keeps track of
that for you.
3) elements with no explicit namespace prefix either are not in a
namespace at all, or belong to the namespace mapped to the "default"
namespace in scope, i.e. the one declared with a xmlns="..."
declaration, as opposed to a xmlns:prefix="..." one.
Again, people rarely remap the "default" (missing) namespace prefix in
their documents to differing namespaces.
And that's IT. How can you say that it's THAT complicated ;-)
I consider it unfriendly to map a given NS prefix to more than one NS
in a given file, and to not declare all namespaces in the root
element, especially if there is a "default" namespace.
Stop spreading false information about namespaces Steve ;-))) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource (was Re: archivefileset resources)
Posted by Steve Loughran <st...@apache.org>.
Matt Benson wrote:
> --- Steve Loughran <st...@apache.org> wrote:
> Maybe. :) But really, I appreciate your input. I
> have no problem admitting how clueless I am wrt xml in
> general and ns in particular. :|
rule 1 of xml: nobody understands XML namespaces
rule 2: anybody who says they do. still doesnt.
so there are the following categories
-ignorant of xmlns
-vaguely aware, but doesnt understand
-think they understand, but doesnt really
-knows xmlns enough to know it doesnt make sense, and doesnt understand
if you meet someone who thinks they do understand it, ask them if, in
xml schema, the ##local namespace is in ##other, or not.
For the record, I know enough for them to scare me, that's it.
>
>> have had to deal with
>> exactly this kind of problem in the past, where we
>> really did have to
>> extract and maintain the xmlns list. And believe me,
>> Xom does not go out
>> of its way to make that easy
>>
>
> Can we mitigate any of this with usage guidelines?
> Three ways to resolve a type, the first two of which
> are easy:
>
> - use a type in a globally defined ns
> - use e.g antlib:org.foo/type
1.
> - use a type in a globally defined ns
kind of breaks some of the xmlns rules
2.
> - use e.g antlib:org.foo/type
this is somewhat similar to how XPath lets you insert new XMLNS
declarations. If you were do it, I'd prefer
{http://example.org}type as that is equivalent to how
javax.xml.QName.toString() works
3.
> third option would require awareness of available
> namespaces at the time of resolution, so if you
> defined
>
> <property name="resource" value="myns:type?blah" />
>
> you'd have to say:
>
> <echo output="${resource}"
> xmlns:myns="antlib:org.myorg" />
>
> or whatever... does that solve and/or accomplish
> anything?
it would certainly work, but be unduly painful. Your task would need to
know which namespace declarations to put i for a resource, which then
becomes something you can't change.
Other options
-make a QName an official Ant type. When you set it, the XMLNS gets
expanded. This is a good idea anyway; too bad QNAme is only built in to
java5, though javax.xml.namespace is available as an add-on for older code.
you could create one in the qname task
<qname ns="http://org.example/" local="local" > ==
{http://org.example/}local
<qname local="local" > == {}local
<qname ns="something" > == BuildException no local
<qname value="prefix:value" > == {lookup(prefix)}value ... xmlns:prefix
would have to be up the tree
Of course, this doesnt help you with the problem of defining resource
destinations in a string, or a properties file...
-Make an xmlns context something else that is a datatype
<namespaces id="here" /> //cache all defined xmlns in this element's
scope
<namespaces refid="here" /> //extract the namespaces and add them to the
parent node (i.e. the target)
<echo output="${resource}" />
Not sure whether I like that one.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource (was Re: archivefileset resources)
Posted by Matt Benson <gu...@yahoo.com>.
--- Steve Loughran <st...@apache.org> wrote:
> Stefan Bodewig wrote:
> > On Wed, 21 Mar 2007, Matt Benson
> <gu...@yahoo.com> wrote:
> >
> >> I think what is needed is a well-known syntax
> specification for
> >> specifying a string representation of
> [resource-type][String to pass
> >> to constructor] e.g. "file?/foo/bar.baz",
> >> "url?http://www.apache.org", "string?blah blah
> blah".
> >
> > This is so I can say
> >
> > <unzip
> >
>
src="url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> >
> > instead of
> >
> > <unzip>
> > <url
>
url="http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> > </unzip>
> >
> > right?
> >
> > Sounds right.
>
>
> >
> >> This is to all intents and purposes the only way,
> IMHO, to seriously
> >> take advantage in Ant tasks of our early decision
> to design
> >> getOutputStream() into the Resource contract.
> You'll notice my use
> >> of the "?" character above to indicate the
> preceding text was the
> >> name of a currently available type. I used "?"
> because for xmlns as
> >> well as fs reasons I'm pretty sure this character
> should NOT be a
> >> colon.
> >
> > I agree that a colon would be a bad choice, at
> least if we allow file
> > ressources to be specified without a prefix. I
> don't really see any
> > conflict with xmlns.
>
> ah, this is starting to scare me.
Then my work is done! ;)
>
> you'd need qname resolution in string to support
> custom resources
>
> <unzip
>
>
src="tns:url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
>
> I hate those because they only resolve relative to
> where they are defined
>
> <property name="url"
>
value="tns:url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"
> xmlns:tns="http://example.org" />
>
> this defines the url property with the tns namespace
> in scope
>
> but where it is used, it may be absent
>
> <unzip
> src="${url}">
>
> or defined to something else
>
> <unzip
> src="${url}" xmlns:tns="http://something-else"/>
>
> So you're going to have to retaiin the entire list
> of in-scope XMLNS
> declarations in every property you define. Now, what
> if its a custom
> task that creates the string? is
> Project.setNewProperty() going to have
> to take a reference to the node in the DOM graph
> where the current task
> is working?
>
>
> You may think I'm being a troublemaker here, but I
Maybe. :) But really, I appreciate your input. I
have no problem admitting how clueless I am wrt xml in
general and ns in particular. :|
> have had to deal with
> exactly this kind of problem in the past, where we
> really did have to
> extract and maintain the xmlns list. And believe me,
> Xom does not go out
> of its way to make that easy
>
Can we mitigate any of this with usage guidelines?
Three ways to resolve a type, the first two of which
are easy:
- use a type in a globally defined ns
- use e.g antlib:org.foo/type
third option would require awareness of available
namespaces at the time of resolution, so if you
defined
<property name="resource" value="myns:type?blah" />
you'd have to say:
<echo output="${resource}"
xmlns:myns="antlib:org.myorg" />
or whatever... does that solve and/or accomplish
anything?
br,
Matt
> >
> >> However I'm not sure what the RIGHT "trigger
> character" is and IMO
> >> this is the only outstanding question stopping us
> from adding this
> >> feature to Ant.
>
> that and how to correctly handle xml namespaces.
>
> -steve
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource (was Re: archivefileset resources)
Posted by Steve Loughran <st...@apache.org>.
Stefan Bodewig wrote:
> On Wed, 21 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
>
>> I think what is needed is a well-known syntax specification for
>> specifying a string representation of [resource-type][String to pass
>> to constructor] e.g. "file?/foo/bar.baz",
>> "url?http://www.apache.org", "string?blah blah blah".
>
> This is so I can say
>
> <unzip
> src="url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
>
> instead of
>
> <unzip>
> <url url="http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> </unzip>
>
> right?
>
> Sounds right.
>
>> This is to all intents and purposes the only way, IMHO, to seriously
>> take advantage in Ant tasks of our early decision to design
>> getOutputStream() into the Resource contract. You'll notice my use
>> of the "?" character above to indicate the preceding text was the
>> name of a currently available type. I used "?" because for xmlns as
>> well as fs reasons I'm pretty sure this character should NOT be a
>> colon.
>
> I agree that a colon would be a bad choice, at least if we allow file
> ressources to be specified without a prefix. I don't really see any
> conflict with xmlns.
ah, this is starting to scare me.
you'd need qname resolution in string to support custom resources
<unzip
src="tns:url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
I hate those because they only resolve relative to where they are defined
<property name="url"
value="tns:url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"
xmlns:tns="http://example.org" />
this defines the url property with the tns namespace in scope
but where it is used, it may be absent
<unzip
src="${url}">
or defined to something else
<unzip
src="${url}" xmlns:tns="http://something-else"/>
So you're going to have to retaiin the entire list of in-scope XMLNS
declarations in every property you define. Now, what if its a custom
task that creates the string? is Project.setNewProperty() going to have
to take a reference to the node in the DOM graph where the current task
is working?
You may think I'm being a troublemaker here, but I have had to deal with
exactly this kind of problem in the past, where we really did have to
extract and maintain the xmlns list. And believe me, Xom does not go out
of its way to make that easy
>
>> However I'm not sure what the RIGHT "trigger character" is and IMO
>> this is the only outstanding question stopping us from adding this
>> feature to Ant.
that and how to correctly handle xml namespaces.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 24 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
>
>> On Fri, 23 Mar 2007, Matt Benson
>> <gu...@yahoo.com> wrote:
>> > --- Stefan Bodewig <bo...@apache.org> wrote:
>> Not that bad. IH already favor setters for anything that's not a
>> string over a plain String setter. But IH already is a pretty
>> complex beast ...
>
> Right, the whole thing is it favors those non-String
> setters once, for good and all, at construction. So
> by the time you're actually using it, under the
> current implementation, your IH instance has already
> made up its mind what type "src" is, and it would be
> random if we don't at least go in and say Resource
> trumps File. It would take more surgery to make IH
> store e.g. a map of property names to (map of types to
> AttributeSetters); currently it maps name directly to
> AttributeSetter.
Later in my post I already agreed it would be simpler to do it that
way than try to resolve a ressource and fall back to File at the time
we want to execute the setter. We agree by now.
>> >> bikeshedding? 8-)
> <http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING>
>
> I've read that one. So I wonder what's the one I
> said,
You said:
>> >> > However I'm not sure what the RIGHT "trigger character" is and
>> >> > IMO this is the only outstanding question stopping us from adding
>> >> > this feature to Ant.
Which I read as "I'm, not sure what the right color of the bikeshed is
and IMO this is the only outstanding question stopping us from
building the bike".
Again, I was joking.
>> >> OK, what is left? "#", "="? Or
>> >> "url(http://www.apache.org/)"?
>> >
>> > I kind of liked the parentheses thing when I saw it...
>> > I wonder if it looks too much like a method call.
>>
>> parens might look strange when use in a regexp mapper, curly braces
>> might be better and they don't even look like a method call.
>
> For arguments' sake :) {} appear to be used at least
> in the java1.4 regexp package. But we're talking
> about mapper RESULTS ("to" attr) so that narrows
> things considerably. Maybe the choice of character(s)
> will be a necessary evil in some contexts.
8-)
So simply go ahead, implement the Ressource as an attribute stuff
using your preferred trigger and maybe have a vote if anybody objects.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Fri, 23 Mar 2007, Matt Benson
> <gu...@yahoo.com> wrote:
> > --- Stefan Bodewig <bo...@apache.org> wrote:
>
> >> I guess we'd need something dynamic, i.e. there
> has to be a way to
> >> register a ressource prefix with RU so that I can
> have string
> >> representations for my own ressource types.
> >
> > I had assumed we could specify things in such a
> way as
> > to specify the resource type simply by its
> typedef,
>
> For some reason I never made that connection, even
> though it is
> obvious. That's why I didn't see a conflict with
> XML namespaces
> either.
>
> > but I suppose a shortcoming of doing it this way
> is
> > that for types from antlibs they must be
> explicitly
> > typedef'd or have their ns mapped. Well, I
> suppose
> > e.g.
> >
> > antlib:org.foo/customResource?bar
> >
> > wouldn't be the end of the world,
>
> I don't think it would be too much to simply require
> ressources to be
> typedef'ed if you want to use the String ->
> Ressource magic.
>
> >> For BC we'd have to keep the File-argument
> setters anyway. IH
> >> could be changed to use setSrc(Ressource) in
> favor of setSrc(File)
> >> and use the later if no ressource mapping was
> found. No real need
> >> to have a default in RU. OTOH it might be
> convenient for users
> >> when they can simply omit the "file?" prefix for
> files.
> >>
> >
> > That'd be quite a bit of IH modification to make
> it
> > preserve > 1 type for a given property.
>
> Not that bad. IH already favor setters for anything
> that's not a
> string over a plain String setter. But IH already
> is a pretty complex
> beast ...
Right, the whole thing is it favors those non-String
setters once, for good and all, at construction. So
by the time you're actually using it, under the
current implementation, your IH instance has already
made up its mind what type "src" is, and it would be
random if we don't at least go in and say Resource
trumps File. It would take more surgery to make IH
store e.g. a map of property names to (map of types to
AttributeSetters); currently it maps name directly to
AttributeSetter. Not impossible, but modifies the
original design enough that it really no longer makes
sense to throw out String either in that case. You
see?
>
> > I can't decide what would be the best all-around
> solution, but it
> > does seem that if we overloaded the same property
> setters with File
> > and Resource, it might be easiest overall to add
> explicit code that
> > setSrc(File) won't override setSrc(Resource) in IH
> (maybe no type
> > can override a Resource),
>
> would be easy, similar code already exists in IH.
>
> > then default to FileResources as planned.
>
> OK.
>
> >> > However I'm not sure what the RIGHT "trigger
> character" is and
> >> > IMO this is the only outstanding question
> stopping us from adding
> >> > this feature to Ant.
> >>
> >> bikeshedding? 8-)
> >
> > I get those little allegories mixed up. Is that
> the
> > one where we can blab back and forth forever, but
> > ultimately whoever is doing the work can make the
> > choice?
>
> Not really. It means we might be spending too much
> energy on
> discussing minor details (the color of the bike
> shed) while there are
> bigger problems to tackle.
>
>
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING>
>
I've read that one. So I wonder what's the one I
said, or did I make it up or put a few together? ;)
> Even though you sounded as if the choice of
> character was the only
> thing that prevented us from implementing the
> feature, I was not
> accusing anybody of wasting our time. I was joking.
>
> > Actually, globmapper doesn't seem to support ?.
> ;)
>
> Ack, I should have known that. The regexp mapper
> does, though ;-)
>
Right, though for optional expression components
rather than as a single-character wildcard. :)
> >> OK, what is left? "#", "="? Or
> >> "url(http://www.apache.org/)"?
> >
> > I kind of liked the parentheses thing when I saw
> it...
> > I wonder if it looks too much like a method call.
>
> parens might look strange when use in a regexp
> mapper, curly braces
> might be better and they don't even look like a
> method call.
>
For arguments' sake :) {} appear to be used at least
in the java1.4 regexp package. But we're talking
about mapper RESULTS ("to" attr) so that narrows
things considerably. Maybe the choice of character(s)
will be a necessary evil in some contexts.
-Matt
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 23 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
>> I guess we'd need something dynamic, i.e. there has to be a way to
>> register a ressource prefix with RU so that I can have string
>> representations for my own ressource types.
>
> I had assumed we could specify things in such a way as
> to specify the resource type simply by its typedef,
For some reason I never made that connection, even though it is
obvious. That's why I didn't see a conflict with XML namespaces
either.
> but I suppose a shortcoming of doing it this way is
> that for types from antlibs they must be explicitly
> typedef'd or have their ns mapped. Well, I suppose
> e.g.
>
> antlib:org.foo/customResource?bar
>
> wouldn't be the end of the world,
I don't think it would be too much to simply require ressources to be
typedef'ed if you want to use the String -> Ressource magic.
>> For BC we'd have to keep the File-argument setters anyway. IH
>> could be changed to use setSrc(Ressource) in favor of setSrc(File)
>> and use the later if no ressource mapping was found. No real need
>> to have a default in RU. OTOH it might be convenient for users
>> when they can simply omit the "file?" prefix for files.
>>
>
> That'd be quite a bit of IH modification to make it
> preserve > 1 type for a given property.
Not that bad. IH already favor setters for anything that's not a
string over a plain String setter. But IH already is a pretty complex
beast ...
> I can't decide what would be the best all-around solution, but it
> does seem that if we overloaded the same property setters with File
> and Resource, it might be easiest overall to add explicit code that
> setSrc(File) won't override setSrc(Resource) in IH (maybe no type
> can override a Resource),
would be easy, similar code already exists in IH.
> then default to FileResources as planned.
OK.
>> > However I'm not sure what the RIGHT "trigger character" is and
>> > IMO this is the only outstanding question stopping us from adding
>> > this feature to Ant.
>>
>> bikeshedding? 8-)
>
> I get those little allegories mixed up. Is that the
> one where we can blab back and forth forever, but
> ultimately whoever is doing the work can make the
> choice?
Not really. It means we might be spending too much energy on
discussing minor details (the color of the bike shed) while there are
bigger problems to tackle.
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING>
Even though you sounded as if the choice of character was the only
thing that prevented us from implementing the feature, I was not
accusing anybody of wasting our time. I was joking.
> Actually, globmapper doesn't seem to support ?. ;)
Ack, I should have known that. The regexp mapper does, though ;-)
>> OK, what is left? "#", "="? Or
>> "url(http://www.apache.org/)"?
>
> I kind of liked the parentheses thing when I saw it...
> I wonder if it looks too much like a method call.
parens might look strange when use in a regexp mapper, curly braces
might be better and they don't even look like a method call.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource (was Re: archivefileset resources)
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Wed, 21 Mar 2007, Matt Benson
> <gu...@yahoo.com> wrote:
>
> > I think what is needed is a well-known syntax
> specification for
> > specifying a string representation of
> [resource-type][String to pass
> > to constructor] e.g. "file?/foo/bar.baz",
> > "url?http://www.apache.org", "string?blah blah
> blah".
>
> This is so I can say
>
> <unzip
>
>
src="url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
>
> instead of
>
> <unzip>
> <url
>
url="http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> </unzip>
>
> right?
Yes; additionally, and more usefully perhaps:
<echo output="file?foo">foo</echo>
as a replacement for
<echo file="foo">foo</echo>
In general I suppose I have always seen this concept
as being most useful for specifying output either with
tasks' attributes/properties or with mappers. Then
again, anyplace the resource could be specified in
this inline fashion suggests higher ease-of-use;
overriding a property from the command line could use
an entirely different resource as source, destination,
etc. for a given operation.
>
> Sounds right.
>
> > One may recall this as something I've been after
> for awhile--I
> > consider it the "next step" for resource handling
> in Ant. For code
> > compartmentalization we could probably add the
> code to generate a
> > Resource from a String to ResourceUtils, but IH
> would know how to
> > use e.g. RU.getResource(Project, String) to set
> Resource attributes
>
> I guess we'd need something dynamic, i.e. there has
> to be a way to
> register a ressource prefix with RU so that I can
> have string
> representations for my own ressource types.
>
I had assumed we could specify things in such a way as
to specify the resource type simply by its typedef,
but I suppose a shortcoming of doing it this way is
that for types from antlibs they must be explicitly
typedef'd or have their ns mapped. Well, I suppose
e.g.
antlib:org.foo/customResource?bar
wouldn't be the end of the world, and of course
xmlns:foo="antlib:org.foo"
+
foo:customResource?bar
would be the preferred way of doing this; also having
the long form available would mean one could add an
antlib with -lib, set a property with the long form,
and now custom resources from a given antlib can be
injected into a build that has no knowledge
of/dependency on that antlib. Weird. :)
> > (for BC, FileResource would be the default).
>
> For BC we'd have to keep the File-argument setters
> anyway. IH could
> be changed to use setSrc(Ressource) in favor of
> setSrc(File) and use
> the later if no ressource mapping was found. No
> real need to have a
> default in RU. OTOH it might be convenient for
> users when they can
> simply omit the "file?" prefix for files.
>
That'd be quite a bit of IH modification to make it
preserve > 1 type for a given property. I can't
decide what would be the best all-around solution, but
it does seem that if we overloaded the same property
setters with File and Resource, it might be easiest
overall to add explicit code that setSrc(File) won't
override setSrc(Resource) in IH (maybe no type can
override a Resource), then default to FileResources as
planned. Otherwise IH will have to have its internals
changed quite a bit to maintain knowledge of multiple
potential property types.
> > This is to all intents and purposes the only way,
> IMHO, to seriously
> > take advantage in Ant tasks of our early decision
> to design
> > getOutputStream() into the Resource contract.
> You'll notice my use
> > of the "?" character above to indicate the
> preceding text was the
> > name of a currently available type. I used "?"
> because for xmlns as
> > well as fs reasons I'm pretty sure this character
> should NOT be a
> > colon.
>
> I agree that a colon would be a bad choice, at least
> if we allow file
> ressources to be specified without a prefix. I
> don't really see any
> conflict with xmlns.
This goes back to my idea of simply using the
registered type name to denote the resource desired,
hence the conflict with xmlns if a user were to use a
custom resource in a namespaced antlib. :)
>
> > However I'm not sure what the RIGHT "trigger
> character" is and IMO
> > this is the only outstanding question stopping us
> from adding this
> > feature to Ant.
>
> bikeshedding? 8-)
I get those little allegories mixed up. Is that the
one where we can blab back and forth forever, but
ultimately whoever is doing the work can make the
choice?
>
> "?" isn't pretty but works for me. "@" would
> probably work nicely
> (file@/usr/local/bin/xemacs) but may get unwieldy if
> you use constant
> ressource specifications inside of macrodefs (you'd
> have to double the
> "@"). No obvious choice IMHO, I'd take whatever you
> pick.
>
Agreed wrt @.
> > Aside from allowing IH to transform a String into
> a given Resource,
> > you'll see that tasks using mappers can choose to
> pass the mapped
> > names to this same factory code and work with
> resources, or they can
> > behave as normal and they will break if a user
> tries to map to an
> > arbitrary resource type
>
> Sounds good.
>
> > (assuming its string representation can't be
> misinterpreted as a
> > file, a situation I hope we'll be able to prevent
> esp. by choosing
> > the right "trigger character").
>
> There won't be any such character. AFAIK the only
> forbidden character
> in Unix filenames is a / and this obviously is a
> very bad choice for
> the "trigger". "?" and "*" are unlikely in
> filenames, but both are
> used as wildcards in patterns - now that you mention
> using the string
> representation in mappers:
>
> <globmapper from="file?*.xml"
> to="url?http://home/*.html"/>
>
> Here the "?" might look ambiguos.
Actually, globmapper doesn't seem to support ?. ;)
Also, remember that mapping would ordinarily be
undertaken by passing in getName(), e.g. the part of a
filename beyond the basedir. So ordinarily the full
resource representation wouldn't include the resource
type and all. Really mappers are kind of kludgy as
they require a lot of implicit knowledge on how to use
them--I'm pretty sure there are places in Ant that use
mappers slightly differently anyway. :|
>
> OK, what is left? "#", "="? Or
> "url(http://www.apache.org/)"?
I kind of liked the parentheses thing when I saw it...
I wonder if it looks too much like a method call.
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org