ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: Namespace support in ant 1.6
Date Tue, 11 Nov 2003 15:09:16 GMT
On Tuesday 11 November 2003 14:39, Jose Alberto Fernandez wrote:
> I think the right thing, technically, is to use (b),
> however due to the way conditions where defined (using class extension)
> and due to the fact that <if> extends condition, this makes for a very
> ugly result. Is there a way to redefine antcontrib's <if> to make it
> show a syntax like (c) eventhough is using (b) rules?

The simplest way is to introduce roles.
Then the conditions would be simple typedefs.
Roles would needed to distinguish between, for example
<or> as a condition and <or> as a file selector.

The role feature (based on your original role work)
consists of specifing the context in which the typedef is
valid for.
So
<typedef name="or" 
         classname="org.apache.tools.ant.taskdefs.condition.Or"
	 role="org.apache.tools.ant.taskdefs.condition.Condition"/>

<typedef name="or"
         classname="org.apache.tools.ant.types.selectors.OrSelector"
         role="org.apache.tools.ant.types.selectors.FileSelector"/>

would define two ant types, one of which may be used as a condition
and the other may be used as a selector.

I have also being thinking of another possiblity, have
a attribute on the typedef specifing that there are multiple
definitions for this name

<typedef name="or" multidef="yes"
         classname="org.apache.tools.ant.taskdefs.condition.Or" />

<typedef name="or" multidef="yes"
         classname="org.apache.tools.ant.types.selectors.OrSelector" />

Ant will then use the best matching "or" for the context.
or perhaps:

<typedef name="or"> 
   <class name="org.apache.tools.ant.taskdefs.condition.Or"/>
   <class name="org.apache.tools.ant.types.selectors.OrSelector"/>
</typedef>

Ant would then use the first class that is valid for the context.

Peter
>
> I guess I do not want to just provide our own implementation, but to
> prove that we can offer a way for third parties to reshuffle their
> code a little, and gain having nice NS syntax.
>
> Ideas?
>
> Jose Alberto
>
> > -----Original Message-----
> > From: peter reilly [mailto:peter.reilly@corvil.com]
> > Sent: 10 November 2003 18:21
> > To: Ant Developers List
> > Subject: Namespace support in ant 1.6
> >
> >
> > Hi,
> > I would like to get some movement on the outstanding issues
> > if ant 1.6.
> >
> > One of the outstanding issues is what namespace to use
> > for nested elements of tasks. (Discovered by introspection rules).
> >
> > The choices are:
> >   a) Use the default ant namespace, this is the current rule.
> >   b) Use the namespace of the enclosing task or type.
> >   c) Allow either - let the build script author choose.
> >
> > Using the if task from ant-contrib and assuming an
> > project tag of <project xmlns:antcontrib="antlib:net.sf.antcontrib"
> > as an example:
> >
> > Choice a)
> >
> > <antcontrib:if>
> >    <or>
> >       <equals arg1="a" arg2="${x}"/>
> >       <antcontrib:ispropertytrue property="y"/>
> >    </or>
> >    <then>
> >       <echo>both conditions are true</echo>
> >    </then>
> > </antcontrib:if>
> >
> > Choice b)
> >
> > <antcontrib:if>
> >    <antcontrib:or>
> >       <antcontrib:equals arg1="a" arg2="${x}"/>
> >       <antcontrib:ispropertytrue property="y"/>
> >    </antcontrib:or>
> >    <antcontrib:then>
> >       <echo>both conditions are true</echo>
> >    </antcontrib:then>
> > </antcontrib:if>
> >
> >
> > Choice c)
> >
> > (one could use a) or b) or this)
> > <antcontrib:if>
> >    <or>
> >       <equals arg1="a" arg2="${x}"/>
> >       <antcontrib:ispropertytrue property="y"/>
> >    </or>
> >    <antcontrib:then>
> >       <echo>both conditions are true</echo>
> >    </antcontrib:then>
> > </antcontrib:if>
> >
> >
> > Peter
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message