The problem of not using namespaces is that they would not be backward compatible. Also the attributes are 'magic' and we already have 'id' as a magic attribute, which makes task code hard to reason about. Peter p.s, I really hate xml namespaces!
On Thu, May 9, 2013 at 4:43 PM, Jean-Louis Boudart < jeanlouis.boud...@gmail.com> wrote: > I'm not a big fan of adding this feature through internal namespaces, was > there any complication to do it without namespaces ? > > Anyway it does the job, and stuff looks extensible so i'm fine with current > solution if no one objects. > > 49036 add 'unless' attribute to JUnit test element was already solved > isn't it ? > > > > 2013/5/6 Peter Reilly <peter.kitt.rei...@gmail.com> > > > wow, I had forgot about that! > > > > Peter > > > > > > On Mon, May 6, 2013 at 12:55 AM, Antoine Levy Lambert <anto...@gmx.de > > >wrote: > > > > > Hi, > > > > > > I have committed a patch created by Peter Reilly back in 2007. > > > > > > The bugzilla PR is 43362 [1] > > > > > > If the community is happy with this change we will be able to close a > > > number of bug reports requesting if/unless on various elements . > > > For instance 49136 requesting if/unless support for attribute nested > > > element of manifest task, > > > 49036 add 'unless' attribute to JUnit test element, > > > ... > > > > > > Regards, > > > > > > Antoine > > > > > > [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43362 > > > > > > On May 3, 2013, at 5:37 AM, Jan Matèrne (jhm) wrote: > > > > > > > AFAIK this was discussed several times in the past (few years) with > the > > > > result, that having if/unless an _all_ elements would decrease > > > > maintainability of the build scripts. > > > > > > > > But +1 from me for having if/unless on nested elements. > > > > > > > > What about supporting more complex conditions via nested <condition> > > > > elements? > > > > > > > > > > > > Jan > > > > > > > >> -----Ursprüngliche Nachricht----- > > > >> Von: Michael Clarke [mailto:michael.m.cla...@gmail.com] > > > >> Gesendet: Freitag, 3. Mai 2013 11:01 > > > >> An: Ant Developers List > > > >> Betreff: Re: Adding if/unless conditions on commandline args > > > >> > > > >> +1 from me too > > > >> > > > >> On 3 May 2013, at 09:37, Jean-Louis Boudart > > > >> <jeanlouis.boud...@gmail.com> wrote: > > > >> > > > >>> +1 > > > >>> > > > >>> > > > >>> 2013/5/3 Antoine Levy Lambert <anto...@gmx.de> > > > >>> > > > >>>> I wonder whether we could not add if an unless on all nested > > > >> elements > > > >>>> in the framework ? > > > >>>> > > > >>>> > > > >>>> Regards, > > > >>>> > > > >>>> Antoine > > > >>>> On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote: > > > >>>> > > > >>>>> Hi, > > > >>>>> > > > >>>>> It's currently difficult to make reusable script when using > <exec> > > > >>>>> task > > > >>>> or > > > >>>>> any other task using commandline args. > > > >>>>> We oftenly need some "dynamic arguments" and this can be > > > >> complicated. > > > >>>>> > > > >>>>> Therefor, i suggest to introduce if/unless conditions on comand > > > >> line > > > >>>> args : > > > >>>>> > > > >>>>> <exec executable="git"> > > > >>>>> <arg value="commit"/> > > > >>>>> <arg line="-a" if="${commit.all.files}"/> <arg value="-m"/> > <arg > > > >>>>> value="${commit.message}"/> </exec> > > > >>>>> > > > >>>>> I have a working implementation with related tests and > > > >> documentation. > > > >>>>> Commandline.Arg class now extends ProjectComponent, and expose > > > >>>>> accessors for if/unless condition, and rely on PropertyHelper to > > > >> check conditions. > > > >>>>> > > > >>>>> Is this sufficient ? From what i have seen, it doesn't break > > > >>>>> backward compatibility at least all tests are green :p. > > > >>>>> > > > >>>>> The setProject(Project p) method should be invoked > "automatically" > > > >>>>> by ProjectHelper isn't it ? > > > >>>>> > > > >>>>> If ant is used in pure java and we ommited invoking > > > >>>>> setProject(Project p) method, it should also works as > > > >> PropertyHelper seems null safe. > > > >>>>> > > > >>>>> If there is no objection i will commit this this week end. > > > >>>> > > > >>>> > > > >>>> > -------------------------------------------------------------------- > > > >> - > > > >>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For > > > >> additional > > > >>>> commands, e-mail: dev-h...@ant.apache.org > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> -- > > > >>> Jean Louis Boudart > > > >>> Independent consultant > > > >>> Apache EasyAnt commiter http://ant.apache.org/easyant/ > > > >> > > > >> > --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For > additional > > > >> commands, e-mail: dev-h...@ant.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > > > For additional commands, e-mail: dev-h...@ant.apache.org > > > > > > > > > > > > > > > > -- > Jean Louis Boudart > Independent consultant > Apache EasyAnt commiter http://ant.apache.org/easyant/ >
