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. +31 (0)70 340 4931
[EMAIL PROTECTED]
http://www.epo.org
"Peter Reilly" <[EMAIL PROTECTED]>
14-01-2008 17:52
Please respond to
"Ant Developers List" <[email protected]>
To
"Ant Developers List" <[email protected]>
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 <[EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]
> http://www.epo.org
>
>
>
>
> "Dominique Devienne" <[EMAIL PROTECTED]>
> 14-01-2008 17:17
> Please respond to
> "Ant Developers List" <[email protected]>
>
>
> To
> "Ant Developers List" <[email protected]>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
>
> On 1/14/08, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > "Dominique Devienne" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]