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:[EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
