Re: [gradle-dev] dependency layer refactoring

[Adam Murdoch]

Hans Dockter wrote: What about doing things differently?   We could introduce a Configuration class which implements Task. One can add dependencies to a configuration. Executing such a task means resolving its dependencies. Such a task would offer also methods to get a path, list of files, etc ... The compile task for example would depends on its configuration task(s). A project dependency would establish a depends relation between the configuration it belongs to and the configuration of the other project. The artifact producing configuration of the other project would depend on the corresponding artifact task(s).   This would remove unnecessary elements from our API. It decreases the learning curve and simplifies the design. Last but not least we have finally our Configuration object to express this important domain concept. I think this is an excellent idea. We already do something similar (conceptually) for bundles: A task is added to the project for each bundle produced by the project, and I can ask that a bundle be built from the command-line, add dependencies on it, query it for its location, etc. We could probably come up with a common approach for configurations and bundles.  This approach would extend nicely to other types of artifacts a build could produce (eg reports, releases, etc) and maybe even more generally into other types of build domain concepts, such as app servers (eg I need this app server to be running in order to deploy to it). I'm not sure if Configuration should implement Task, or whether adding a Configuration would trigger the adding of a Task that resolves it.  The problem with implementing Task is that there are (at least) 2 interpretations of 'executing' a configuration: resolving it, and producing/publishing it. By adding a task instead, we have the option of adding both a resolve task and a publish task for a configuration. I guess another option would be to have 2 types of Configuration: one for incoming dependencies and one for produced artifacts. Adam --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email