On Jan 10, 2008 9:33 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Jan 10, 2008 2:13 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <[EMAIL PROTECTED]> > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
