ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Date Thu, 10 Jan 2008 20:46:06 GMT
On Jan 10, 2008 9:33 PM, Dominique Devienne <> wrote:

> On Jan 10, 2008 2:13 PM, Xavier Hanin <> wrote:
> > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <>
> > > 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.



> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Xavier Hanin - Independent Java Consultant

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