Hi Adam,
On Jul 30, 2008, at 5:17 AM, Adam Murdoch wrote:
Hi,
I'd like to provide some feedback on the changes to
DependencyManager, in particular the changes for mapping
configuration <-> task.
I don't think method names such as linkConfWithTask(), getConfs4Task
(), and so on, really convey the meaning of what is being
modelled. There are 2 types of task - configuration
relationships: One is the relationship between a configuration and
a task that consumes it,
Right. Before the last changes a task could only "consume" one
configuration. No it can consume multiple ones. The compile task for
a War project for example can now consume the 'compile' and
'provided' configuration.
the other is the relationship between a configuration and a task
which *produces* it.
I don't see a use case relationship. Any examples?
The current method names don't really describe which of these
relationships they refer to. I think it would be nice to model both
types of relationships more explicitly.
There are a number of methods on DependencyManager which take a
configuration name as their first parameter, or return a map
indexed by configuration name. This suggests a missing domain
object, which would represent a configuration and which could be
used to configure, query, resolve and publish the configuration
(I'm not referring to ivy's Configuration object here, though we
would end up converting each configuration to one of these). I
think it would be good to have a strong domain model for the things
which the build produces, not just how it produces them.
I completely agree with the objectives. For example the fact that
there are n:n relationships between tasks and configurations is not
expressed clearly by the model but just 'implemented' with two maps
and some methods within another class. Adding a configuration object
as you have proposed looks like a good idea. I have field a Jira:
http://jira.codehaus.org/browse/GRADLE-171
One reason why things are as they are, is that the script has been
driving the model.
I'd love to do continuous peer reviews particularly on domain driven
design aspects. Unfortunately Codehaus does not offer Atlassians
Crucible.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
