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, the
other is the relationship between a configuration and a task which
*produces* it. 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.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
