ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <peter.kitt.rei...@gmail.com>
Subject Re: Adding if/unless conditions on commandline args
Date Thu, 09 May 2013 18:42:43 GMT
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.boudart@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.reilly@gmail.com>
>
> > wow, I had forgot about that!
> >
> > Peter
> >
> >
> > On Mon, May 6, 2013 at 12:55 AM, Antoine Levy Lambert <antoine@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.clarke@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.boudart@gmail.com> wrote:
> > > >>
> > > >>> +1
> > > >>>
> > > >>>
> > > >>> 2013/5/3 Antoine Levy Lambert <antoine@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-unsubscribe@ant.apache.org For
> > > >> additional
> > > >>>> commands, e-mail: dev-help@ant.apache.org
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Jean Louis Boudart
> > > >>> Independent consultant
> > > >>> Apache EasyAnt commiter http://ant.apache.org/easyant/
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For
> additional
> > > >> commands, e-mail: dev-help@ant.apache.org
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > > > For additional commands, e-mail: dev-help@ant.apache.org
> > > >
> > >
> > >
> >
>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://ant.apache.org/easyant/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message