Steve Appling wrote:
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)
I wonder if we should verify those things that contribute to the project
at runtime, instead. We probably don't care about verifying those things
that contribute only to the test runtime.
That is, test and check all projects in the runtime 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?
We don't necessarily have to do this generally, at least initially. It
would be ok to hardcode this for a handful of tasks provided by the java
plugin for starters.
A general solution again comes down to declaring the input and/or output
artifacts for a task. If we know the inputs artifacts for a task, we can
traverse this back through configurations and projects. And forward from
the output artifacts. I'm hoping we'll see something fall out of the
source dir domain objects.
I don't necessarily think this is a great idea, I was just throwing out
options to see if we could come up with something good.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
