Hi, I also figured out that if and unless prefix are not going to mask potential if or unless attributes already existing in custom types or data types. I was glad to see that the patch was still usable with little manual work after so many years in Bugzilla. I did not try to create an implementation without namespaces, no idea whether this would be easy or not. Antoine
Peter Reilly <peter.kitt.rei...@gmail.com> a écrit : >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/ >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
