On Jul 30, 2008, at 12:08 PM, Adam Murdoch wrote:
Hans Dockter wrote:
Hi Adam,
On Jul 30, 2008, at 5:17 AM, Adam Murdoch wrote:
the other is the relationship between a configuration and a task
which *produces* it.
I don't see a use case relationship. Any examples?
One example is a project which uses the artifacts of another
project in a multi-project build. Currently we use
DependencyManager.artifactProductionTaskName to model this, which
ProjectDependency uses to add a task dependency from the consuming
project to the producing task of the project. This is fine when all
public configurations of a project are produced by a single task
and are cheap to build. A problem I ran into porting a multi-
project ant build to gradle is that some configurations were very
expensive to build and were not needed by most of the other
projects. However, in order to use any of them in another project,
I was forced to build all of them whether required or not.
I'm not sure if I understand the example above correctly. As I
understand it, 'configuration project dependencies' as described at
the end of section 14.6 in the UG might help (e.g. new
ProjectDependency(project(':api'), 'spi')).
I also think some consistency between modelling the consumers of a
configuration and the producers of a configuration would help
understandability.
Configurations in Ivy have two aspects. One is internal for a
project, like compile, testCompile, etc which are needed for building
the project. The other aspect is an external one. You use
configurations to bundle artifacts produced by a project (like 'spi'
in the example above). When you talk about a producer of
configurations, is this equivalent to a producer of artifacts?
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
