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.
3. Add support for a command line syntax that can limit the scope of the
dependencies that are used. 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 (and probably after the
check). 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
