On Jan 10, 2008 9:33 PM, Dominique Devienne <ddevienne@gmail.com> wrote:

> On Jan 10, 2008 2:13 PM, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <peter.arrenbrecht@gmail.com>
> > > Providing
> > > override hooks is all well and good, but that is still basically the
> > > very controlled and rigit maven approach, I think.
> >
> > It depends on what you accept to do in your override. If the build
> system
> > somewhat relies on Ant import mechanism, you are able to override  any
> > target defined by the build system. In the end if you have something
> very
> > specific the worst that could happen is override everything, making the
> > build system useless except it first provided a structure. But at least
> you
> > are always free, which is not the case with maven.
>
> Maven's override hooks are a good thing IMHO. The problem with Ant is
> that you have to provide them explicitly in the ''abstract'' build
> file so that the ''concrete'' build can override them, as opposed to
> Maven's hooks, where you simply define in pre-goal in the concrete
> build without any need to modify the abstract build.
>
> It's the C++ where all class methods are non-virtual by default, and
> and Java where there's virtual by default. Unless the class is
> specifically designed not to be extended, the Java way is more
> flexible because you can often intercept the virtual call and make
> your pre and post processing there. (let's not go into philosophical
> flame about the good or bad of this please)
>
> Having the ability to say in Ant <target before="compile"/> or <target
> after="deploy"/> with no need to add explicit -pre-compile or
> -post-deploy hooks in the base build would already simplify things
> when customizing a base build, and make it more ''hackable''.

I was thinking about something even more flexible based on events: <target
on="before:compile" />. Then all you need is trigger events at the beginning
and the end of each target. The problem is that either solutions require
changes in Ant.

Similarly, an explicit <target override="compile"/> to explicitly
> completely replace a base target is better IMHO to the implicit
> override that currently happens, and makes the build file more
> readable/explicit about the intent. --DD

True, pretty much like the @Override introduced in Java 5.


> PS: The before/after target would be moot is <target override>
> supported a nested <super/> element. That's a syntax that would flow
> better IHMO.

Yes, would be a nice improvement too. But in my mind I was more thinking
about a build system based on current Ant feature set and syntax, at least
for a first version. Unless several Ant committers would like to get
involved and target a new Ant version to support the new build system.

Opinions?

Xavier

>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


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