"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] IBM WebSphere Application Server WAS Release Engineering
