Hans Dockter wrote:
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?
Sorry, I meant to say archives instead of bundles, ie we do something
similar for archives (make them available as tasks which other tasks can
depend on). Hopefully that makes more sense.
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.
This makes sense. So, for example, if I have a project that produces an
artifact and includes it in a configuration, I add an Archive (task) to
produce the artifact, then add a Configuration (task) with a dependency
on the archive task. Adding this dependency declares that the archive is
a publication included in the configuration.
If I want to use the configuration in my project, I add another task
with a dependency on the configuration task. Adding this dependency
declares that the task uses the configuration. Before my task is
executes, the archive is built, the configuration is resolved, and my
task can query the Configuration object for the files that make up the
configuration.
If I want to include artifacts from another project, I can add a
dependency from the configuration task to a configuration task in the
other project. I can add more artifacts to the configuration by adding
more dependencies on archive tasks (or any file producing task, really).
I can add external dependencies (log4j, say) by adding them directly to
the configuration task.
Where do you think publishing would happen in all this?
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
