On Jan 15, 2008 6:31 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > "Peter Reilly" <[EMAIL PROTECTED]> writes: > > > I would say that if the build file does not specify the order, then the > order > > is undefined. > > > > If the order is important, then the build file can enforce an order by > > using "depends". > > > > <target name="prepare" before="junit" depends="start-server"> > > <prepare /> > > </target> > > One thing we are not taking into account is the plugin approach that > is part of Xavier's initial EasyAnt vision. > > If our base build file contains a compile target and several "plugins" > that I want to use need to do stuff before the compile target then we > need a way to have a defined order. In the order my build file > requires the plugins, I guess.
Yes, I agree order should be predictable, and keeping definition order seems fine. > > > Do we revert the order for after targets so the first one declared > gets executed last? Why not. But in my mind if you really need to do something surrounding a target, you'd better use the around mechanism than the after / before. I think it's more explicit. The problem with the around mechanism as I see it (which is basically an override with a mean to call the original definition) is the interaction between plugins. If several plugins use the around mechanism, it maybe difficult to understand that the call to the original defintion actually call the definition overriden by another plugin. And if one plugin actually overrides a definition without calling the original definition, then the order will be very important: if it's defined after a plugin overriding just for the around, then I guess the final override will override everything including the overriden definition. So it's very different from what would have happened while using a before and after targets (well, as I see it, see below). > > > Also we will need to define how before/after an complete overriding of > targets interact. Do before/after apply to the new definition of the > target or are they dropped? I'd say they apply to the new definition. If we take the example of the server start / stop, I think it still makes sense to run 'em when another plugin redefines how the unit tests are run. In my mind plugins interactions should be kept minimal as long as they aren't explicitly desired. If a plugin really wants to disable another plugin 'before' target, then we should provide a mean to do it, like overriding the before target. I'm not sure if there is a use case for that though. As I said before the main problem about plugin interaction is when two plugins override the definition of a target, and at least one doesn't call the original definition. Maybe this shouldn't be considered at the same level: defining before and after targets can be seen as a plugin contribution. Overriding a target is closer to OO inheritance, and as such maybe could be allowed only when a build script 'extends' another one. Hence we would have two kind of relationship between build modules: - a build module 'contributes' to another one, in which case it can only define after/before targets. This is called a plugin. - a build module 'extends' another one, in which case it can override parent target(s) definition(s) Only one 'extension' of a given module can be used at a time in the build system, while the number of contributions is not limited. Does this make sense? Xavier > > > Stefan > > --------------------------------------------------------------------- > 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/
