ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <peter.kitt.rei...@gmail.com>
Subject Re: Location in non-Task tasks
Date Mon, 11 Sep 2006 15:04:13 GMT
On 9/11/06, Matt Benson <gudnabrsam@yahoo.com> wrote:
>
> --- Dominique Devienne <ddevienne@gmail.com> wrote:
>
> > > >> However, it is a pity that AssetTask has to
> > extend
> > > >> ConditionBase ... oh well.
> > > >
> > > > It doesn't "have to", does it? All it needs is
> > an add(Condition)
> > > > method, no?
> > >
> > > No.  Most of the "old" conditions are not
> > <typedef>ed and so don't
> > > have a "name" of their own, you can't add them to
> > a task that only has
> > > add(Condition).
> >
> > What is preventing us from declaring them? OK,
> > typedef'ing them would
> > probably create some havoc and name conflict.
> >
> > Now that we have add(Type) introspection (what I
> > also call extension
> > points), we should *really* get away from being
> > forced to derive from
> > ConditionBase or similar base classes. I see two
> > ways to allow this:
> >
> > 1) Have an Ant-conditions antlib, and force users of
> > AntUnit to
> > explicit load it, with or without using an XML
> > namespace. I'd be fine
> > with this myself.
>
> Steve introduced said antlib in the 1.7 codebase.


it is in  antlib:org.apache.tools.ant.taskdefs.condition
(possibly should be in o.a.t.a.types.condition !)

>
> > 2) Introduce a <tagdef> or <roledef> for the purpose
> > of locating
> > extension points as nested elements. They differ
> > from <typedef>s in
> > that they don't allow to declare these 'tags' at the
> > top-level, but
> > only as nested-elements of another type or task.
> >
>
> This is interesting but quite possibly too complicated
> to make 1.7 .


I had (have if I can find it) some code in IH (IntrospectionHelper) to do
this
but I looked at the code and realized that the type
handling in ant would become too complicated - there
would be a number of classes corresponding to the name
"x" and at runtime, ant (IH) would pick the "best" one depending
on the class that corresponded to the container element.
I realized that this would not be general/usefull enough for
third party antlib libraries - it would rare that the same name
woud be used for multiple contexts and the current simple
name -> class mapping is sufficient. Therefore the only use
for the complicted type lookup would be for core-ant names that map
to multiple ant classes depending on the role
- "or", "and" "xor", and a small number of others.
It would however be nice to get something that
allows add(Condition) or add(FileSelector) to work
without having to extend BaseCondition or whatever
is done for FileSelector .


Peter


>   In any event, there are similarities
> here with my recent change to ConditionBase to
> implement DynamicElement and look up unknown elements
> in the aforementioned antlib.  We actually need to
> finish that conversation on-list before 1.7 final as
> well; I'll ping that thread.  :)




-Matt
>
> > What do you think? --DD
> >
> >
> ---------------------------------------------------------------------
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message