On Tuesday 11 November 2003 09:33, Antoine Lévy-Lambert wrote: > Which of the 3 solutions you propose is the best in terms of preparing the > transition to 1.7 and roles ? The third. > > And the easiest to understand for users ? The first. (I think). The second for people that want to write xml syntax grammers for their tasks/types. The third will allow build files to be written without worrying too much about the issues. (like we do at the moment for the case of elements and attributes)
> How can we formulate the rules in terms of when an xml prefix such as > antcontrib: is required ? When is it optional ? Not easy, the prefix depends on the implementation of the element- whether it is implemented by addName() or by a typedef. > > On the details side, I did not understand why you did not prefix with > antcontrib the <then/> tag in your original example a ? The <then> is not prefixed since it is implemented by an addThen() method. Note that the antelope implementation of <if/> implemented <then> as a task, and so in that case it would be <antcontrib:/> in all cases. > And in the example b, I did not understand either why you prefixed with > antcontrib: the <then/> tag. The b) rule is that nested elements inherit the namespace uri of their parent unless the nested element is a typedef'ed element. > > Also, do you mean that everything in this regard would be more clear as > soon as we have roles ? I am not sure. Peter > > Cheers, > > Antoine > > -----Ursprüngliche Nachricht----- > Von: peter reilly [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 11. November 2003 10:15 > An: Ant Developers List > Betreff: Re: AW: Namespace support in ant 1.6 > > On Tuesday 11 November 2003 08:57, Antoine Levy-Lambert wrote: > > >Von: peter reilly [mailto:[EMAIL PROTECTED] > > >Gesendet: Montag, 10. November 2003 19:21 > > >An: Ant Developers List > > >Betreff: Namespace support in ant 1.6 > > > > > > > > >Hi, > > >I would like to get some movement on the outstanding issues > > >of ant 1.6. > > > > +1 > > > > >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: > > > > Do <or/> and <equals/> in your example come from ant core ? I guess so, > > but > > > <then> comes from ant-contrib, no ? > > The <or/> and <equals/> come from > org.apache.tools.ant.taskdefs.condition.ConditionBase > which is extended by > net.sf.antcontrib.logic.IfTask, > thus, as seen by introspection, they come > from the IfTask class, hence the "antcontrib" prefix. > > Of course, in ant1.7 when roles get sorted out, > <or/> and <equals/> will be taskdef'ed elements as well as hardcoded > methods of ConditionBase. > > Peter > > > I would have expected your examples a and b to be like this : > > > > Choice a) > > > > <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> > > > > > > Choice b) > > > > <antcontrib:if> > > <antcore:or> > > <equals arg1="a" arg2="${x}"/> > > <antcontrib:ispropertytrue property="y"/> > > </antcore:or> > > <then> > > <antcore:echo>both conditions are true</antcore:echo> > > <then> > > </antcontrib:if> > > > > > > Cheers, > > > > Antoine > > > > > > --------------------------------------------------------------------- > > 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]
