On Aug 22, 2009, at 12:46 AM, Adam Murdoch wrote:
Hans Dockter wrote:
On Aug 1, 2009, at 6:40 PM, Steve Appling wrote:
I would like to use the java multiproject sample in an integration
test for the new build* tasks that can include dependents or
dependees (still REALLY need good names for these). Currently
both the :api and the :services:webservice project have a project
execution dependency on the :shared project (a Project.dependsOn
'shared'). This will defeat the changes I am making, it forces
test in :api to depend on test in :shared. Is there a need for
these two project to have a project execution dependency - I would
like to remove it.
Those dependsOn declarations were historic residues. Good that you
have removed them.
Another note. I find the term Project Dependency used
inconsistently in the users guide. Project dependencies as
described in section 29.6.1.3 refers to a "Project.dependsOn"
relationship. I think these are called project execution
dependencies in other areas of the user guide.
Section 26.3.4 also describes "Project Dependencies", but these
are the "dependencies { compile project(':shared') }" type of
dependency which is very different. This is called a project lib
dependency in other parts of the user guide (although I think I
like project artifact dependency better).
These are still confusingly similar - I have found myself
discussing project dependency with someone at my company and we
were each referring to different types of project dependencies. I
don't really have more discriminating names than what I described
above, however.
If I have the correct terminologies here, I'll update the user
guide to make these consistent when I check in documentation for
the Java Plugin task changes I am making.
I'm not sure about the best terminology here. One way of phrasing
is would be to call project.dependsOn a project dependency and
<someConf> project('a') a project artifact dependency. But the
latter is much more common than the first. So using project
execution dependencies and project dependencies might be the best
way of doing things. Updating the user's guide would be excellent.
I'm wondering if we should get rid of Project.dependsOn(), and just
leave Project.evaluationDependsOn(). Is there a good use case which
project artifact dependencies does not solve?
One use case is our own multi-project build. Without project execution
dependencies we need to write in the root project:
clean.dependsOn subprojects*.clean
task javadoc(overwrite: true, dependsOn: subprojects*.javadoc)
task groovydoc(overwrite: true, dependsOn: subprojects*.groovydoc)
task check(overwrite: true, dependsOn: subprojects*.check)
task test(overwrite: true, dependsOn: subprojects*.test)
If we declare project execution dependencies from root to the
children, we can do:
dependsOnChildren()
task javadoc(overwrite: true)
task groovydoc(overwrite: true)
task check(overwrite: true)
task test(overwrite: true)
So we get the aggregation behavior for free. (BTW: What is awkward at
the moment. is that we have to overwrite the root project tasks as we
use the groovy-plugin. I haven't gotten around to get rid of the
plugin but will do so soon.)
I'm not saying that this use case is absolutely compelling but it
points to something. We might replace the dependsOn method with an
aggregate method. This aggregate method could define a rule, that
aggregates any task of a project passed as an argument to the
aggregate method. In our case (provided the root project does not uses
the groovy plugin), 'aggregate subprojects' would do what we want
without the necessity to create any aggregator task (with the current
dependsOn method you would still have to create placeholder tasks for
the tasks you want to aggregate).
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
