[DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Peter Reilly-2]

Why not have something simple like having a "before" and "after" attributes to
the <target> element.

<project  ...>
    ...
   <import file="${commons.dir}/ant-setup.xml"/>   <!-- defines common
build, junit, javadoc etc -->

   <target name="start-server" before="junit">
      <start-server/>
   </target>


  <target name="stop-server" after="junit">
     <stop-the-server/>
   </target>


</target>

Peter

On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <whaefelinger@...> wrote:

> > So every concrete simple target like <target name="foo" depends="bar,
> > baz" /> became
> >
> > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > <target name="-foo" > ... </target>
> > <target name="-pre-foo" />
> > <target name="-post-foo" />
>
> This looks pretty ugly this me!
>
> I believe that this whole discussion focusses too much on targets
> instead of macros. Macros are a very powerfull feature and they
> deserve much more attention!
>
> Why not simply:
>
> <!-- === framework === -->
> <target name="foo" depends="bar,baz" description="public foo target">
>   <foo />
> </target>
>
> <macrodef name="foo" >
>   <sequential>
>     <!-- to the foo thing -->
>   </sequential>
> </macrodef>
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> <macrodef name="foo">
>   <sequential>
>     <echo> before original foo ..</echo>
>
>     <c:foo />       <!-- assume framework in NS "c" />
>
>     <echo> after original foo .. </echo>
>   </sequential>
> </macrodef>
>
>
> Notice that I'm only using the name "foo" and not "-post-foo" and all
> your other names.
>
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. [phone]
> whaefelinger@...
> http://www.epo.org
>
>
>
>
> "Dominique Devienne" <ddevienne@...>
> 14-01-2008 17:17
> Please respond to
> "Ant Developers List" <dev@...>
>
>
> To
> "Ant Developers List" <dev@...>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
>
> On 1/14/08, Stefan Bodewig <bodewig@...> wrote:
> > "Dominique Devienne" <ddevienne@...> writes:
> > Having something like before/after/around advices (where around is the
> > same as an override that doesn't change the dependencies list) may
> > suffice and leave overwriting the whole target definition to the worst
> > case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:
>
> So every concrete simple target like <target name="foo" depends="bar,
> baz" /> became
>
> <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> <target name="-foo" > ... </target>
> <target name="-pre-foo" />
> <target name="-post-foo" />
>
> in the "abstract" build. Override -foo to replace just the target
> content, without it's dependency list. Or override foo to have
> complete control, but in my experience it's -foo that needed
> overriding, not foo.
>
> Note though that unlike before and after, around isn't as
> representative a name. When I thought about this issue a while back, I
> thought of using a magic name such as "super" in the depends attribute
> to refer to the overridden target's dependency list, similar to using
> <super/> in the target's body to refer to the overridden target's task
> list/content. --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ddevienne]

On 1/14/08, Peter Reilly <peter.kitt.reilly@...> wrote:
> Why not have something simple like having a "before" and "after" attributes to
> the <target> element.

This is indeed something we discussed and proposed earlier in the
thread. (except I envisioned the before/after to be used instead of
the name attribute, although giving a more explicit name to the target
is a good optional think I now realize, and is independent of the
target being "injected" into the dependency chain at the correct
place).

But is it that simple? If you have several such before/after targets,
what order are they executed in? What is they are spread into several
files? And if you give them names, do these before/after targets
themselves become override-able?

Even this simple (very desirable!) feature can get hairy when one digs
a little before the surface. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Wolfgang Häfelinger]

Assume also:

   <target name="prepare" before="junit">
      <prepare />
   </target>

Do you want this before your "start-server" or after it or
in parallel?

And you you need to extend Ant with "before" and "after" of
course.


Regards,

Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. [phone]
whaefelinger@...
http://www.epo.org




"Peter Reilly" <peter.kitt.reilly@...>
14-01-2008 17:52
Please respond to
"Ant Developers List" <dev@...>


To
"Ant Developers List" <dev@...>
cc

Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects






Why not have something simple like having a "before" and "after"
attributes to
the <target> element.

<project  ...>
    ...
   <import file="${commons.dir}/ant-setup.xml"/>   <!-- defines common
build, junit, javadoc etc -->

   <target name="start-server" before="junit">
      <start-server/>
   </target>


  <target name="stop-server" after="junit">
     <stop-the-server/>
   </target>


</target>

Peter

On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <whaefelinger@...> wrote:

> > So every concrete simple target like <target name="foo" depends="bar,
> > baz" /> became
> >
> > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > <target name="-foo" > ... </target>
> > <target name="-pre-foo" />
> > <target name="-post-foo" />
>
> This looks pretty ugly this me!
>
> I believe that this whole discussion focusses too much on targets
> instead of macros. Macros are a very powerfull feature and they
> deserve much more attention!
>
> Why not simply:
>
> <!-- === framework === -->
> <target name="foo" depends="bar,baz" description="public foo target">
>   <foo />
> </target>
>
> <macrodef name="foo" >
>   <sequential>
>     <!-- to the foo thing -->
>   </sequential>
> </macrodef>
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> <macrodef name="foo">
>   <sequential>
>     <echo> before original foo ..</echo>
>
>     <c:foo />       <!-- assume framework in NS "c" />
>
>     <echo> after original foo .. </echo>
>   </sequential>
> </macrodef>
>
>
> Notice that I'm only using the name "foo" and not "-post-foo" and all
> your other names.
>
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. [phone]
> whaefelinger@...
> http://www.epo.org
>
>
>
>
> "Dominique Devienne" <ddevienne@...>
> 14-01-2008 17:17
> Please respond to
> "Ant Developers List" <dev@...>
>
>
> To
> "Ant Developers List" <dev@...>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
>
> On 1/14/08, Stefan Bodewig <bodewig@...> wrote:
> > "Dominique Devienne" <ddevienne@...> writes:
> > Having something like before/after/around advices (where around is the
> > same as an override that doesn't change the dependencies list) may
> > suffice and leave overwriting the whole target definition to the worst
> > case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:
>
> So every concrete simple target like <target name="foo" depends="bar,
> baz" /> became
>
> <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> <target name="-foo" > ... </target>
> <target name="-pre-foo" />
> <target name="-post-foo" />
>
> in the "abstract" build. Override -foo to replace just the target
> content, without it's dependency list. Or override foo to have
> complete control, but in my experience it's -foo that needed
> overriding, not foo.
>
> Note though that unlike before and after, around isn't as
> representative a name. When I thought about this issue a while back, I
> thought of using a magic name such as "super" in the depends attribute
> to refer to the overridden target's dependency list, similar to using
> <super/> in the target's body to refer to the overridden target's task
> list/content. --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Peter Reilly-2]

On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <whaefelinger@...> wrote:
> Assume also:
>
>    <target name="prepare" before="junit">
>       <prepare />
>    </target>
>
> Do you want this before your "start-server" or after it or
> in parallel?
>

I would say that if the build file does not specify the order, then the order
is undefined.

If the order is important, then the build file can enforce an order by
using "depends".

    <target name="prepare" before="junit" depends="start-server">
       <prepare />
    </target>

Peter

> And you you need to extend Ant with "before" and "after" of
> course.
>
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. [phone]
> whaefelinger@...
> http://www.epo.org
>
>
>
>
> "Peter Reilly" <peter.kitt.reilly@...>
> 14-01-2008 17:52
>
> Please respond to
> "Ant Developers List" <dev@...>
>
>
> To
> "Ant Developers List" <dev@...>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
> Why not have something simple like having a "before" and "after"
> attributes to
> the <target> element.
>
> <project  ...>
>     ...
>    <import file="${commons.dir}/ant-setup.xml"/>   <!-- defines common
> build, junit, javadoc etc -->
>
>    <target name="start-server" before="junit">
>       <start-server/>
>    </target>
>
>
>   <target name="stop-server" after="junit">
>      <stop-the-server/>
>    </target>
>
>
> </target>
>
> Peter
>
> On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <whaefelinger@...> wrote:
> > > So every concrete simple target like <target name="foo" depends="bar,
> > > baz" /> became
> > >
> > > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > > <target name="-foo" > ... </target>
> > > <target name="-pre-foo" />
> > > <target name="-post-foo" />
> >
> > This looks pretty ugly this me!
> >
> > I believe that this whole discussion focusses too much on targets
> > instead of macros. Macros are a very powerfull feature and they
> > deserve much more attention!
> >
> > Why not simply:
> >
> > <!-- === framework === -->
> > <target name="foo" depends="bar,baz" description="public foo target">
> >   <foo />
> > </target>
> >
> > <macrodef name="foo" >
> >   <sequential>
> >     <!-- to the foo thing -->
> >   </sequential>
> > </macrodef>
> >
> >
> > If a user then really need to override "foo", he or she would simply
> > write in build.xml something like
> >
> >
> > <macrodef name="foo">
> >   <sequential>
> >     <echo> before original foo ..</echo>
> >
> >     <c:foo />       <!-- assume framework in NS "c" />
> >
> >     <echo> after original foo .. </echo>
> >   </sequential>
> > </macrodef>
> >
> >
> > Notice that I'm only using the name "foo" and not "-post-foo" and all
> > your other names.
> >
> >
> > Regards,
> >
> > Wolfgang Häfelinger
> > Research & Architecture | Dir. 2.7.0.2
> > European Patent Office
> > Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> > Tel. [phone]
> > whaefelinger@...
> > http://www.epo.org
> >
> >
> >
> >
> > "Dominique Devienne" <ddevienne@...>
> > 14-01-2008 17:17
> > Please respond to
> > "Ant Developers List" <dev@...>
> >
> >
> > To
> > "Ant Developers List" <dev@...>
> > cc
> >
> > Subject
> > Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> > projects
> >
> >
> >
> >
> >
> >
> >
> > On 1/14/08, Stefan Bodewig <bodewig@...> wrote:
> > > "Dominique Devienne" <ddevienne@...> writes:
> > > Having something like before/after/around advices (where around is the
> > > same as an override that doesn't change the dependencies list) may
> > > suffice and leave overwriting the whole target definition to the worst
> > > case.
> >
> > Thanks for reminding me of this issue Stefan. Indeed, something I
> > really didn't like about overriding the whole target, is that you had
> > to duplicate the dependency list as well...
> >
> > Which is why I now remember that I now remember I used 4, not 3
> > targets, in the "abstract" build, the forth one being the target's own
> > content, separate from its dependency list:
> >
> > So every concrete simple target like <target name="foo" depends="bar,
> > baz" /> became
> >
> > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > <target name="-foo" > ... </target>
> > <target name="-pre-foo" />
> > <target name="-post-foo" />
> >
> > in the "abstract" build. Override -foo to replace just the target
> > content, without it's dependency list. Or override foo to have
> > complete control, but in my experience it's -foo that needed
> > overriding, not foo.
> >
> > Note though that unlike before and after, around isn't as
> > representative a name. When I thought about this issue a while back, I
> > thought of using a magic name such as "super" in the depends attribute
> > to refer to the overridden target's dependency list, similar to using
> > <super/> in the target's body to refer to the overridden target's task
> > list/content. --DD
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Peter Reilly-2]

On Jan 14, 2008 5:24 PM, Peter Reilly <peter.kitt.reilly@...> wrote:

> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <whaefelinger@...> wrote:
> > Assume also:
> >
> >    <target name="prepare" before="junit">
> >       <prepare />
> >    </target>
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the order
> is undefined.
>

This would be similar to the @Before and @After annotations in junit.
Peter

> If the order is important, then the build file can enforce an order by
> using "depends".
>
>     <target name="prepare" before="junit" depends="start-server">
>        <prepare />
>     </target>
>
> Peter
>
> > And you you need to extend Ant with "before" and "after" of
> > course.
> >
> >
> > Regards,
> >
> > Wolfgang Häfelinger
> > Research & Architecture | Dir. 2.7.0.2
> > European Patent Office
> > Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> > Tel. [phone]
> > whaefelinger@...
> > http://www.epo.org
> >
> >
> >
> >
> > "Peter Reilly" <peter.kitt.reilly@...>
> > 14-01-2008 17:52
> >
> > Please respond to
> > "Ant Developers List" <dev@...>
> >
> >
> > To
> > "Ant Developers List" <dev@...>
> > cc
> >
> > Subject
> > Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> > projects
> >
> >
> >
> >
> >
> >
> > Why not have something simple like having a "before" and "after"
> > attributes to
> > the <target> element.
> >
> > <project  ...>
> >     ...
> >    <import file="${commons.dir}/ant-setup.xml"/>   <!-- defines common
> > build, junit, javadoc etc -->
> >
> >    <target name="start-server" before="junit">
> >       <start-server/>
> >    </target>
> >
> >
> >   <target name="stop-server" after="junit">
> >      <stop-the-server/>
> >    </target>
> >
> >
> > </target>
> >
> > Peter
> >
> > On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <whaefelinger@...> wrote:
> > > > So every concrete simple target like <target name="foo" depends="bar,
> > > > baz" /> became
> > > >
> > > > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > > > <target name="-foo" > ... </target>
> > > > <target name="-pre-foo" />
> > > > <target name="-post-foo" />
> > >
> > > This looks pretty ugly this me!
> > >
> > > I believe that this whole discussion focusses too much on targets
> > > instead of macros. Macros are a very powerfull feature and they
> > > deserve much more attention!
> > >
> > > Why not simply:
> > >
> > > <!-- === framework === -->
> > > <target name="foo" depends="bar,baz" description="public foo target">
> > >   <foo />
> > > </target>
> > >
> > > <macrodef name="foo" >
> > >   <sequential>
> > >     <!-- to the foo thing -->
> > >   </sequential>
> > > </macrodef>
> > >
> > >
> > > If a user then really need to override "foo", he or she would simply
> > > write in build.xml something like
> > >
> > >
> > > <macrodef name="foo">
> > >   <sequential>
> > >     <echo> before original foo ..</echo>
> > >
> > >     <c:foo />       <!-- assume framework in NS "c" />
> > >
> > >     <echo> after original foo .. </echo>
> > >   </sequential>
> > > </macrodef>
> > >
> > >
> > > Notice that I'm only using the name "foo" and not "-post-foo" and all
> > > your other names.
> > >
> > >
> > > Regards,
> > >
> > > Wolfgang Häfelinger
> > > Research & Architecture | Dir. 2.7.0.2
> > > European Patent Office
> > > Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> > > Tel. [phone]
> > > whaefelinger@...
> > > http://www.epo.org
> > >
> > >
> > >
> > >
> > > "Dominique Devienne" <ddevienne@...>
> > > 14-01-2008 17:17
> > > Please respond to
> > > "Ant Developers List" <dev@...>
> > >
> > >
> > > To
> > > "Ant Developers List" <dev@...>
> > > cc
> > >
> > > Subject
> > > Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> > > projects
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 1/14/08, Stefan Bodewig <bodewig@...> wrote:
> > > > "Dominique Devienne" <ddevienne@...> writes:
> > > > Having something like before/after/around advices (where around is the
> > > > same as an override that doesn't change the dependencies list) may
> > > > suffice and leave overwriting the whole target definition to the worst
> > > > case.
> > >
> > > Thanks for reminding me of this issue Stefan. Indeed, something I
> > > really didn't like about overriding the whole target, is that you had
> > > to duplicate the dependency list as well...
> > >
> > > Which is why I now remember that I now remember I used 4, not 3
> > > targets, in the "abstract" build, the forth one being the target's own
> > > content, separate from its dependency list:
> > >
> > > So every concrete simple target like <target name="foo" depends="bar,
> > > baz" /> became
> > >
> > > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > > <target name="-foo" > ... </target>
> > > <target name="-pre-foo" />
> > > <target name="-post-foo" />
> > >
> > > in the "abstract" build. Override -foo to replace just the target
> > > content, without it's dependency list. Or override foo to have
> > > complete control, but in my experience it's -foo that needed
> > > overriding, not foo.
> > >
> > > Note though that unlike before and after, around isn't as
> > > representative a name. When I thought about this issue a while back, I
> > > thought of using a magic name such as "super" in the depends attribute
> > > to refer to the overridden target's dependency list, similar to using
> > > <super/> in the target's body to refer to the overridden target's task
> > > list/content. --DD
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ddevienne]

On 1/14/08, Peter Reilly <peter.kitt.reilly@...> wrote:

> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <whaefelinger@...> wrote:
> > Assume also:
> >
> >    <target name="prepare" before="junit">
> >       <prepare />
> >    </target>
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
>     <target name="prepare" before="junit" depends="start-server">
>        <prepare />
>     </target>

It makes sense Peter. And this already works in Ant, provided we add
before/after support to <target>.

Q1: Does everyone agree that adding before/after to target to Ant 1.8
is useful and should be done before (in conjunction of) creating
generic build files?

Q2: Do others feel (like me) that we should also have a mean to
override a target's content (task list) while keeping the overridden
target's dependency list?

Both questions above are independent of using overriding macros... --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Wolfgang Häfelinger]

> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?

Ok, I'm not a committer - anyhow:

I disagree cause you can do the very same thing just with Macros.
No need for new target attributes.

> Q2: Do others feel (like me) that we should also have a mean to
> override a target's content (task list) while keeping the overridden
> target's dependency list?

This must be the soul of this whole upcoming framework. It's an
absolutley must.





Regards,

Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. [phone]
whaefelinger@...
http://www.epo.org




"Dominique Devienne" <ddevienne@...>
14-01-2008 18:39
Please respond to
"Ant Developers List" <dev@...>


To
"Ant Developers List" <dev@...>
cc

Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects






On 1/14/08, Peter Reilly <peter.kitt.reilly@...> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <whaefelinger@...>
wrote:

> > Assume also:
> >
> >    <target name="prepare" before="junit">
> >       <prepare />
> >    </target>
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the

order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
>     <target name="prepare" before="junit" depends="start-server">
>        <prepare />
>     </target>

It makes sense Peter. And this already works in Ant, provided we add
before/after support to <target>.

Q1: Does everyone agree that adding before/after to target to Ant 1.8
is useful and should be done before (in conjunction of) creating
generic build files?

Q2: Do others feel (like me) that we should also have a mean to
override a target's content (task list) while keeping the overridden
target's dependency list?

Both questions above are independent of using overriding macros... --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Peter Reilly-2]

On Jan 14, 2008 5:39 PM, Dominique Devienne <ddevienne@...> wrote:

> On 1/14/08, Peter Reilly <peter.kitt.reilly@...> wrote:
> > On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <whaefelinger@...> wrote:
> > > Assume also:
> > >
> > >    <target name="prepare" before="junit">
> > >       <prepare />
> > >    </target>
> > >
> > > Do you want this before your "start-server" or after it or
> > > in parallel?
> > >
> >
> > I would say that if the build file does not specify the order, then the order
> > is undefined.
> >
> > If the order is important, then the build file can enforce an order by
> > using "depends".
> >
> >     <target name="prepare" before="junit" depends="start-server">
> >        <prepare />
> >     </target>
>
> It makes sense Peter. And this already works in Ant, provided we add
> before/after support to <target>.

Opps, I just read the previous e-mails, and yes you have proposed this
syntax!.

>
> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?


>
> Q2: Do others feel (like me) that we should also have a mean to
> override a target's content (task list) while keeping the overridden
> target's dependency list?

This is the <target override="build"> syntax?
I am a little dubious, but could be swayed.

Peter
>
> Both questions above are independent of using overriding macros... --DD
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Wolfgang Häfelinger]

> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?

Dominique and Peter,

could you please explain why you see a need for target attributes "before"
and "after" rather
than following the Macro path I proposed?

Regards,

Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. [phone]
whaefelinger@...
http://www.epo.org




"Dominique Devienne" <ddevienne@...>
14-01-2008 18:39
Please respond to
"Ant Developers List" <dev@...>


To
"Ant Developers List" <dev@...>
cc

Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects






On 1/14/08, Peter Reilly <peter.kitt.reilly@...> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <whaefelinger@...>
wrote:

> > Assume also:
> >
> >    <target name="prepare" before="junit">
> >       <prepare />
> >    </target>
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the

order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
>     <target name="prepare" before="junit" depends="start-server">
>        <prepare />
>     </target>

It makes sense Peter. And this already works in Ant, provided we add
before/after support to <target>.

Q1: Does everyone agree that adding before/after to target to Ant 1.8
is useful and should be done before (in conjunction of) creating
generic build files?

Q2: Do others feel (like me) that we should also have a mean to
override a target's content (task list) while keeping the overridden
target's dependency list?

Both questions above are independent of using overriding macros... --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ddevienne]

On 1/14/08, Wolfgang Häfelinger <whaefelinger@...> wrote:
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build files?
>
> could you please explain why you see a need for target attributes "before"
> and "after" rather than following the Macro path I proposed?

I guess because I think in terms of targets and not macros. I've used
macros, but to define new "tasks", not to control the structure of the
build itself. For that, targets and dependencies are the building
blocks IMHO.

At this point I don't understand the macro approach that you advocate,
and even if it worked, I'd argue that it may not be the "natural" way
to add the flexibility we have been discussing about. Could very well
be that I'm wrong, but at this point it's my thinking.

The fact that your macro approach to extensibility works without
changes to Ant is nice but not a strong-enough point to me, if it
feels less natural that the before/after target approach that would
require changes in Ant. I.e. I care more about the user friendliness
and doing it in a simple and natural way, than the implementation
details. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Jan 14, 2008 6:39 PM, Dominique Devienne <ddevienne@...> wrote:

> On 1/14/08, Peter Reilly <peter.kitt.reilly@...> wrote:
> > On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <whaefelinger@...>
> wrote:
> > > Assume also:
> > >
> > >    <target name="prepare" before="junit">
> > >       <prepare />
> > >    </target>
> > >
> > > Do you want this before your "start-server" or after it or
> > > in parallel?
> > >
> >
> > I would say that if the build file does not specify the order, then the
> order
> > is undefined.
> >
> > If the order is important, then the build file can enforce an order by
> > using "depends".
> >
> >     <target name="prepare" before="junit" depends="start-server">
> >        <prepare />
> >     </target>
>
> It makes sense Peter. And this already works in Ant, provided we add
> before/after support to <target>.
>
> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?

I agree, this seems easily understandable (even though when used in
conjunction with depends it may seem a bit complex, but this shouldn't be
needed very often) and use the usual Ant building blocks.

>
>
> Q2: Do others feel (like me) that we should also have a mean to
> override a target's content (task list) while keeping the overridden
> target's dependency list?

I do. And also add the <super /> element you were talking about.

Xavier


>
>
> Both questions above are independent of using overriding macros... --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>


--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Guntis Ozols]

> > > > Assume also:
> > > >
> > > >    <target name="prepare" before="junit">
> > > >       <prepare />
> > > >    </target>
> > > >
> > > > Do you want this before your "start-server" or after it or
> > > > in parallel?
> > > >
> > >
> > > I would say that if the build file does not specify the order,
> > > then the order is undefined.

maybe document order and import tree can be used to define that order?

> > > If the order is important, then the build file can enforce an order by
> > > using "depends".
> > >
> > >     <target name="prepare" before="junit" depends="start-server">
> > >        <prepare />
> > >     </target>
> >
> > It makes sense Peter. And this already works in Ant, provided we add
> > before/after support to <target>.
> >
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build files?
>
> I agree, this seems easily understandable (even though when used in
> conjunction with depends it may seem a bit complex, but this shouldn't
> be needed very often) and use the usual Ant building blocks.
>
> >
> >
> > Q2: Do others feel (like me) that we should also have a mean to
> > override a target's content (task list) while keeping the overridden
> > target's dependency list?
>
> I do. And also add the <super /> element you were talking about.
>
> Xavier

a) override="both"
b) override="content"
c) warn otherwise!

Guntis


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

"Dominique Devienne" <ddevienne@...> writes:

> On 1/14/08, Stefan Bodewig <bodewig@...> wrote:
>> "Dominique Devienne" <ddevienne@...> writes:
>> Having something like before/after/around advices (where around is the
>> same as an override that doesn't change the dependencies list) may
>> suffice and leave overwriting the whole target definition to the worst
>> case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:

I get away with two, but don't get the nice names you use.

<target name="ready-to-do-foo" depends="bar,baz"/>
<target name="foo" depends="-pre-foo">...</target>

and my overriding targets depend on the imported targets to get in the
correct place in the dependency chain.  I.e. a -post-foo target as you
use it would be

<target name="foo" depends="imported:foo">...</target>

> Note though that unlike before and after, around isn't as
> representative a name.

In my case the names come from their usage in Common Lisp so they do
have some precedent.  I agree that around doesn't really describe what
it does.

> When I thought about this issue a while back, I thought of using a
> magic name such as "super" in the depends attribute to refer to the
> overridden target's dependency list, similar to using <super/> in
> the target's body to refer to the overridden target's task
> list/content.

I don't have any problem with super as a magic target name, but I'm
still not convinced of <super/>.  Hmm, maybe we should spawn of
separate threads for the different topics.

<super/> must in some way be taken into account when setting up the
dependency graph of the whole build file which makes it a different
beast from normal tasks.  With before and after attributes on target
you wouldn't need <super/> anymore.

Stefan
--
http://stefan.samaflost.de/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

Wolfgang Häfelinger <whaefelinger@...> writes:

> Why not simply:
>
> <!-- === framework === -->
> <target name="foo" depends="bar,baz" description="public foo target">
>   <foo />
> </target>
>
> <macrodef name="foo" >
>   <sequential>
>     <!-- to the foo thing -->
>   </sequential>
> </macrodef>
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> <macrodef name="foo">
>   <sequential>
>     <echo> before original foo ..</echo>
>  
>     <c:foo />       <!-- assume framework in NS "c" />
>
>     <echo> after original foo .. </echo>
>   </sequential>
> </macrodef>

Can you do <c:foo/> without changes to Ant?

The problems I see with this:

* not idiomatic (no real problem, though)

* requires all targets to consist of a single macro definition

* becomes repetetive with little chance for reuse

  Say I'd like to perform the same action before more than one target

  <target name="my-before" before="foo,bar,baz">
    <do-something/>
  </target>

  instead of

  <macrodef name="foo">
    <sequential>
      <do-something/>
      <c:foo/>
    </sequential>
  </macrodef>
  <macrodef name="bar">
    <sequential>
      <do-something/>
      <c:bar/>
    </sequential>
  </macrodef>
  <macrodef name="baz">
    <sequential>
      <do-something/>
      <c:baz/>
    </sequential>
  </macrodef>

* doesn't factor into the dependency calculation

  taking the example from above, if all three targets foo, bar and baz
  were executed in the same build, the dependencies of my-before would
  only be executed once.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

"Peter Reilly" <peter.kitt.reilly@...> writes:

> I would say that if the build file does not specify the order, then the order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
>     <target name="prepare" before="junit" depends="start-server">
>        <prepare />
>     </target>

One thing we are not taking into account is the plugin approach that
is part of Xavier's initial EasyAnt vision.

If our base build file contains a compile target and several "plugins"
that I want to use need to do stuff before the compile target then we
need a way to have a defined order.  In the order my build file
requires the plugins, I guess.

Do we revert the order for after targets so the first one declared
gets executed last?

Also we will need to define how before/after an complete overriding of
targets interact.  Do before/after apply to the new definition of the
target or are they dropped?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Peter Arrenbrecht]

On Jan 14, 2008 9:37 PM, Xavier Hanin <xavier.hanin@...> wrote:
> On Jan 14, 2008 6:39 PM, Dominique Devienne <ddevienne@...> wrote:
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build files?
>
> I agree, this seems easily understandable (even though when used in
> conjunction with depends it may seem a bit complex, but this shouldn't be
> needed very often) and use the usual Ant building blocks.

I agree. Feels much more natural than macros.

> > Q2: Do others feel (like me) that we should also have a mean to
> > override a target's content (task list) while keeping the overridden
> > target's dependency list?
>
> I do. And also add the <super /> element you were talking about.

I agree. For what it's worth, I think we should also have a means to
externally trigger just the body of a task (mainly during build script
debugging). I normally do

  tgt depend " -tgt"
  -tgt depend "@tgt-step1, @tgt-step2, ..."

Meaning I can call the building blocks @tgt-stepN from outside to
incrementally watch and refine their behaviour.

-peo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Jan 15, 2008 6:31 AM, Stefan Bodewig <bodewig@...> wrote:

> "Peter Reilly" <peter.kitt.reilly@...> writes:
>
> > I would say that if the build file does not specify the order, then the
> order
> > is undefined.
> >
> > If the order is important, then the build file can enforce an order by
> > using "depends".
> >
> >     <target name="prepare" before="junit" depends="start-server">
> >        <prepare />
> >     </target>
>
> One thing we are not taking into account is the plugin approach that
> is part of Xavier's initial EasyAnt vision.
>
> If our base build file contains a compile target and several "plugins"
> that I want to use need to do stuff before the compile target then we
> need a way to have a defined order.  In the order my build file
> requires the plugins, I guess.

Yes, I agree order should be predictable, and keeping definition order seems
fine.

>
>
> Do we revert the order for after targets so the first one declared
> gets executed last?

Why not. But in my mind if you really need to do something surrounding a
target, you'd better use the around mechanism than the after / before. I
think it's more explicit.
The problem with the around mechanism as I see it (which is basically an
override with a mean to call the original definition) is the interaction
between plugins. If several plugins use the around mechanism, it maybe
difficult to understand that the call to the original defintion actually
call the definition overriden by another plugin. And if one plugin actually
overrides a definition without calling the original definition, then the
order will be very important: if it's defined after a plugin overriding just
for the around, then I guess the final override will override everything
including the overriden definition. So it's very different from what would
have happened while using a before and after targets (well, as I see it, see
below).

>
>
> Also we will need to define how before/after an complete overriding of
> targets interact.  Do before/after apply to the new definition of the
> target or are they dropped?

I'd say they apply to the new definition. If we take the example of the
server start / stop, I think it still makes sense to run 'em when another
plugin redefines how the unit tests are run. In my mind plugins interactions
should be kept minimal as long as they aren't explicitly desired. If a
plugin really wants to disable another plugin 'before' target, then we
should provide a mean to do it, like overriding the before target. I'm not
sure if there is a use case for that though. As I said before the main
problem about plugin interaction is when two plugins override the definition
of a target, and at least one doesn't call the original definition. Maybe
this shouldn't be considered at the same level: defining before and after
targets can be seen as a plugin contribution. Overriding a target is closer
to OO inheritance, and as such maybe could be allowed only when a build
script 'extends' another one.

Hence we would have two kind of relationship between build modules:
- a build module 'contributes' to another one, in which case it can only
define after/before targets. This is called a plugin.
- a build module 'extends' another one, in which case it can override parent
target(s) definition(s)

Only one 'extension' of a given module can be used at a time in the build
system, while the number of contributions is not limited.

Does this make sense?

Xavier

>
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>


--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Gilles Scokart]

2008/1/14, Dominique Devienne <ddevienne@...>:

>
> On 1/14/08, Stefan Bodewig <bodewig@...> wrote:
> > "Dominique Devienne" <ddevienne@...> writes:
> > Having something like before/after/around advices (where around is the
> > same as an override that doesn't change the dependencies list) may
> > suffice and leave overwriting the whole target definition to the worst
> > case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:
>
> So every concrete simple target like <target name="foo" depends="bar,
> baz" /> became
>
> <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> <target name="-foo" > ... </target>
> <target name="-pre-foo" />
> <target name="-post-foo" />
>
> in the "abstract" build. Override -foo to replace just the target
> content, without it's dependency list. Or override foo to have
> complete control, but in my experience it's -foo that needed
> overriding, not foo.
>
> Note though that unlike before and after, around isn't as
> representative a name. When I thought about this issue a while back, I
> thought of using a magic name such as "super" in the depends attribute
> to refer to the overridden target's dependency list, similar to using
> <super/> in the target's body to refer to the overridden target's task
> list/content. --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

Using the imported_script_name.target syntax give you already some
flexibility.

--
Gilles Scokart

[ddevienne]

On 1/14/08, Stefan Bodewig <bodewig@...> wrote:
> If our base build file contains a compile target and several "plugins"
> that I want to use need to do stuff before the compile target then we
> need a way to have a defined order.  In the order my build file
> requires the plugins, I guess.

So far we've been talking mostly about a concrete build needing a
customize the behavior of a base generic build, typically with some
pre or post processing, and sometimes complete override of the target
(w/ or w/o changing the dependency list), but when you mentioned the
plugins scenario, it made me think of a "composite" build made up of
several builds you'd import, all with a compile target, where you'd
want the compile targets to somehow "aggregate" into a single compile
target... So instead of doing a <subant> on these builds, you'd import
them, and they "merge" into one build. Sounds a bit crazy, I agree. Oh
well, I'm throwing it out there, but it's probably too weird.

I'd be quite happy if we simply added before/after support, nailing
down the exact desired behavior. Maybe we should indeed do that in
another thread. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gilles Scokart]

By the way, a truly generic build script will probably have to support 2 level of customization/extension.

The first one being an enterprise level, and the second one being at project level.

Gilles




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...