> From: peter reilly [mailto:[EMAIL PROTECTED] > > 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. >
Well, as you may suspect, this is the one I prefer :-) The reason being that the two definitions above may be in separate 3rd party antlibs and hence they are not aware of each other. > 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. This would mean that all antlibs need to agree on allowing multiple names before it can be used at all. > 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. > This would disallow having definitions across antlibs. Which I would prefer to avoid. I know that these shortcommings would be mitigated by using NameSpaces, but yet I still want to be able to lump all my antlibs into the default namespace and use them without namespace stuff. Jose Alberto > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
