Hi, Thanks for the explanation, it indeed seems to be a nice feature, however my first concern would be the order of execution. I can imaging that the easiest way to implement is a first-in-first-out approach (or first-in-first-executed in this matter).
If I understand correctly the target-group, or phase (would be my preference), is a very top-level element that simply specifies a grouping of tasks, it doesn't deal with the order in which tasks are performed. The required order is still defined using the depends attribute on targets. The order of registered targets will be defined by the attribute on the target-group, plus the targets that register themselves once they are loaded (load order is defined by normal processing of targets and imported build files). So, this target-group element is only useful if order doesn't matter in the phase, like in the example of having different types of tests. If order does matter, this would then needed to be solved using the depends attribute. But that also requires making sure that certain targets are not executed twice, which means one would need to add succeeded properties and have unless conditions to check them, right? Or spent time thinking about the order in which targets or build files are imported into the project and processed. Is there a way to solve the issue of ordered execution? I think that would make it even more powerful. In addition, perhaps dynamic inclusion of build files (within targets) can be a valuable extension to this phase feature. Different question, but maybe related: is there a way to specify that a build file should only be imported once (for instance, if different nested files have import statements referring to the same file)? Cheers, Remie On Wed, Nov 12, 2008 at 8:21 AM, Jeffrey E Care <[EMAIL PROTECTED]> wrote: > > "Remie Bolte" <[EMAIL PROTECTED]> wrote on 11/11/2008 11:05:48 AM: > > > Can you explain the concept of targets being able to add themselfs as > > dependencies? > > I can't really picture this :) > > I wasn't involved in the definition of this so don't take my word as > gospel, but this is my understanding: > > Assume you have a lot of projects & want to define a standard set of build > files (with a standard set of targets) for them all to use. You have a > "test" target for each project that can run any number of other targets to > perform specialized testing tasks: load testing, unit testing, etc. > > As things are today your standard test target needs to know about every > potential kind of testing that ANY of the projects MIGHT need to do & add > each of those other targets as a dependency. You basically then have to > define an empty implementation of each one of those specialized targets in > your standard set of build files, otherwise your test target will blow up > when building against one of your projects that doesn't implement some > particular kind of testing. > > This target-group concept turns that around; think of it as dependency > injection. It's defining a target name and saying "Hey, if you want to be > run when I run, please tell me" as opposed to the current situation of "Hey, > I know what I need to do without any help". It's a callback, an extension > point, an event listener, pick a metaphor. > > ____________________________________________________________________________________________ > Jeffrey E. (Jeff) Care [EMAIL PROTECTED] <[EMAIL PROTECTED]> > IBM WebSphere Application Server WAS Release Engineering > > [image: WebSphere Mosiac] [image: WebSphere Brandmark] > >
