Adam Murdoch wrote:
Steve Appling wrote:
<clip>
I think you're just moving the problem by doing this. This would mean
that I can't add a task which depends on the project's tests, such as a
coverage report task, without it also indirectly dragging in the tests
for all the other projects. The tests for a project really don't depend
on the tests for other projects.
A good guiding principle, I reckon, is to have worker tasks such as
compile, test, or jar depend only on the worker tasks they really need,
and have the lifecycle added by lifecycle tasks like build or check
which don't do any work.
If we were to change the above so that:
build -> (all archives), test, check, (test, check of all projects in
the testRuntime configuration)
Then you could do
1a) gradle test
1b) gradle build
2) gradle -a dists test
3a) gradle clean test
3b) gradle clean build
This doesn't require any new command-line options.
I like this with one small change
build -> (all archives), test, check, (test all projects in the testRuntime
configuration), (check all projects in the compile configuration)
The other option, of adding a synthetic tested<task> task would look like:
1a) gradle test
1b) gradle testedLibs
2) gradle -a test
3a) gradle clean test
3a) gradle clean testedLibs
(where testLibs could be testedJar, testedDists, etc)
Another option, would be to add synthetic tasks like:
- <task>Dependents: executes task <task> in all projects which depend on
this project
- <task>Dependees: executes task <task> in all projects which this
project depends on.
1a) gradle test
1b) gradle testDependees
2) gradle -a test
3a) gradle clean test
3b) gradle clean testDependees
and
4) gradle cleanDependents testDependents
I don't generally like the synthetic tasks, but perhaps it will grow on me. One
issue with this is how do you implement the dependents or dependees
functionality for a general task. In other words, what configuration do you
use for a task "fred" to determine dependencies? For a general case solution, I
thought you would have to specify the configuration. This is back in the realm
of command line, but how about syntax like "gradle myconfig*fred" to run the
fred task on all project dependencies in the myconfig configuration (almost like
groovy spread dot). This could be done through an API too to allow the same
facility in the build file:
newtask.dependsOn(configurations.myconfig.tasks('fred')
3. Add support for a command line syntax that can limit the scope of
the dependencies that are used.
A solution really should make it possible to code something up in the
build script, I think. Command-line options should really be treated as
conveniences only.
We should discuss this syntax (and other command line needs) in
another thread, but for this discussion, consider that "gradle
:webapp!:test" would only execute the test task in the webapp project
even though it has dependencies on other projects.
For a project with
root/
common/
webapp/
where the root project has dependsOnChildren().
I think this lets you do all of the above use cases:
1a. gradle :webapp:compile :webapp!:test
1b. gradle :webapp:build
2. gradle :webapp!:build - can possibly get rid of -a
3a.* gradle clean libs :webapp!:test
3b. gradle clean build
Some issues:
*1. From 3a above, I'm not sure this will work as is. This is an area
(one of many) where I may not understand the system enough. I think
that inter-project dependencies are resolved out of the internal cache
and artifacts are only put into the cache from the
uploadDefaultInternal task. In the case of 3a above, I'm not sure
that the libs task will actually put everything in the cache
correctly. I think this is not obvious, however, and probably should
be made to work as shown. uploadDefaultInternal seems like an
implementation detail that users should not have to know about. It
seems like "libs" should be sufficient.
2. I don't think that you can currently specify the order of
dependencies, but I think this is needed to implement a task like
"build". You need to make sure that building the archives happens
before the test
Shouldn't the dependencies of test enforce this?
(and probably after the check).
Why's that?
I'll retract that request for now. You are correct that test's dependency
obviously does what I really cared about in this case. I do think this is
useful, though. I have run into a need for this several times. I will probably
have to do so again before I can remember exactly why :)
I know we have needed this for other tasks in the past. In ant, the
task dependencies are evaluated in the order declared and this is
often very useful.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
