Hans Dockter wrote:
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')).
Say I have a multi-project build (not neccessarily using the java
plugin), where each project has 2 tasks: a 'libs' task, which assembles
some jars for the project, and a 'dists' task, which assembles the
project into some kind of distribution. The 'libs' task publishes a
'libs' configuration, and depends on the 'libs' configuration of other
projects. Similarly, the 'dists' task publishes a 'dists' configuration,
and depends on the 'dists' configuration of other projects. Say that
the 'dists' task is really slow, so that we don't want to execute it if
we're only building the jars for a project.
The ProjectDependency lets me declare that the 'libs' task for a project
depends on the 'libs' config for some other project, and that the
'dists' task depends on the 'dists' config. This is good. What I can't
do is declare that the 'libs' task publishes the 'libs' config and that
the 'dists' task publishes the 'dists' config. All I can do is set
DependencyManager.artifactProductionTaskName, which I would have to set
to 'dists' in this case. Which means that when I only want to build the
jars for a project, I have to build the jars and dists for all the
projects which the project depends on, whereas I only really want to
build the jars for the other projects.
Given that we have a way to tell DependencyManager that a given task
uses a given config, it would be good to also tell DependencyManager
that a given task produces a given config. That is, rename
linkConfWithTask() to something like taskUsesConf(task, conf) and add
something like taskPublishesConf(task, conf)
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?
Good question. I'm talking about the task which publishes the artifacts
for the configuration. I guess this isn't strictly the same as the
task(s) that produce the artifacts themselves.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
