On Aug 6, 2008, at 12:12 PM, Adam Murdoch wrote:
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.
A bundle is a task and at the same time a container for archive tasks
on which it depends. Your analogy is that a configuration is a
container for dependencies, right? But the dependencies are no tasks
yet and I'm not sure if it makes sense to transform them into tasks.
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).
We might create an abstraction for such a task container.
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.
In Ivy itself all configurations are equals. They may contain only
external dependencies or only artifacts produced by the project or
both (e.g. a configuration that exposes the artifacts of a projects
plus its external dependencies). I'm not sure if Ivy misses to model
an important concept.
Our configurations could take the same approach as Ivy. The fact that
a configuration contains artifacts to be produced by the project can
be expressed by the fact that this configuration depends on the
respective archive task. A resolve could be simply defined by calling
an Ivy resolve for the underlying Ivy ocnfiguration.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
