> -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > > For example, let's say I have a compile target I want to import, and > > I want to make it additionally call the "pre" target before and the > > "post" target after. > > Then you don't want to import the target but a different target IMHO.
I disagree ;-) One of my major hope in that import will enable me to keep the same build file API (the targets available to call) across many projects, while being flexible enough to adapt to each project's peculiarities, and reuse/centralize as much as possible of the commonalities in the importable build file. Basically I want the Template Method pattern, which requires override-ability (it's not a word apparently ;-) of methods, or targets in this context. I have two goals: 1) Being able to add pre and/or post processing to an existing target imported. That's what Maven does, and it's quite powerful. Like Nicola Ken, I do not want to have to rename the original target (my goal of keeping the build API consistent, which is very important to my colleagues!) 2) Being able to completely override the default behavior of an imported target. If I recall correctly, Knut (Wannheden) implemented this using XSL and a <super> keyword. I don't really care how my personal goals outlined above are achieved implementation-wise, but I do hope <import> would fulfill them. It doesn't mean that we shouldn't also have an <include>, like XSL does, that basically the same as <import> but errors out in case of any conflicts. Actually, would probably make sense to start with <import>, and then add target overriding on top for <import> IMHO. Thanks, --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
