Steve Appling wrote:
As mentioned in a previous thread, I would like to pull the test task
out of the
normal dependency chain for building an artifact. I think I have at
least the
start of a plan for this and would like some feedback.
There are several use cases of different build/test combinations that
we have
desired in a multi-project system:
1) Incrementally build a single project and all of its dependent projects
a) Test just that project.
b) Test all dependent projects as well.
2) Incrementally build a single project using cached dependencies and
test just that project.
3) Make a clean build of all projects
a) Test just a single project
b) Test all projects
Currently Gradle can do 1b, 2, and 3b. I would like to be able to
handle all of these use cases.
Here's a plan with a few noted holes.
1. Change the java plugin dependencies to something like what Adam
has suggested:
jar -> compile, processResources
libs -> (all jars and wars)
dists -> (all zips and tars)
check -> (all code quality checks)
build -> (all archives), test, check
2. Add a dependency to the test task on the test tasks in all
projects in the testRuntime configuration.
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.
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
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 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.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
