--- Xavier Hanin <[EMAIL PROTECTED]> wrote: > 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? >
1. You yourself are an Ant committer now. ;) 2. Usually it seems we are able to do new things without precluding the old; as long as this is the case I don't see why you, I, we, or somebody else can't do reasonable things to make Any more extensible. $0.02 -Matt > 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/ > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
