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

> 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. +31 (0)70 340 4931
> 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. +31 (0)70 340 4931
> > 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@...
>
>