ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: Ant "roles"
Date Tue, 19 Apr 2005 15:58:38 GMT

--- Stefan Bodewig <bodewig@apache.org> wrote:
> On Tue, 19 Apr 2005, Matt Benson
> <gudnabrsam@yahoo.com> wrote:
> 
> > I think we already have 1. and 2. if we want to
> use
> > antlibs,
> 
> except we don't have the descriptors, yet.
> 
> > and assuming we can place additional resources
> where we like.
> 
> We can.
> 
> >> Something where loading of the descriptor gets
> triggered by the
> >> namespace URI, but this is optional, at least for
> me.
> > 
> > If we have consent to add resources,
> 
> did anybody object?

Sometimes I know what I'm thinking and forget everyone
doesn't.  :)  My concern here is back to this:  I
would like an alternate syntax for loading built-in
antlibs (as I have made painfully clear).  I think
this syntax should be terse and automatically
extensible.  This is why I promote
  ant:foo -> resource org/apache/tools/ant/foo.xml ,
because you can always add another XML file to that
directory and voila, another antlib.  If we cannot use
this or some similar "protocol" then it would probably
make more sense to use the antlibs as usual: e.g.
resourceselectors defined in antlib.xml at
org/apache/tools/ant/types/resources/selectors .

Since antlibs don't accept <import> AFAIK I would hate
to add the same resource (content) in >1 place, which
is why I would like to have the question resolved
before taking any action, if possible.

-Matt

> 
> > then yes, the above is optional, but for me only
> barely so.
> 
> I understand that, and have no problem with adding a
> new ant* protocol
> to shorten this.  It doesn't have to be ant: and it
> doesn't have to be
> antlib:, but even for antlib we could easily make it
> work by adding a
> subprotocol if needed.
> 
> > It almost seems integral that if we are going to
> essentially bundle
> > antlibs in the core, then those should be
> distinguished by a custom
> > means of access, and that as terse as possible.
> 
> Yes, I agree, but it is no show-stopper to me.
> 
> Stefan
> 
>
---------------------------------------------------------------------
> 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


Mime
View raw message