On Jul 24, 2009, at 10:18 AM, Adam Murdoch wrote:
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
What I like with the lifecycle approach is that it introduces a
concept we are talking about a lot. This looks like a good thing. At
the moment is it just designed as an aggregating task but that might
evolve in the future. We might be able to combine it with synthetic
tasks.
1a) gradle test
1b) gradle build
2) gradle buildSingle
3a) gradle clean test
3b) gradle clean build
4.) gradle buildDependents
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
