On Jul 21, 2009, at 6:27 AM, Adam Murdoch wrote:
I don't like the fact that jar depends on test, either. It belongs
somewhere else. We now have a similar problem with the checkstyle
and codenarc tasks, because jar also depends on them (for want of
somewhere else to put them).
I think we need some way to tell Gradle whether or not you want
tested (and checked) artifacts.
A simple option is to add a lifecycle task, called, say 'build' and
move the lifecycle dependencies from 'jar' to 'build', so we end up
with something like:
jar -> compile, processResources
libs -> (all jars and wars)
dists -> (all zips and tars)
check -> (all code quality checks)
build -> (all archives), test, check
This way, 'gradle clean test' will test only the current project. A
downside to this approach is that there's no way to get the existing
behaviour (ie test this project and all projects it depends on).
Another option would be to use implicit tasks for tested vs non-
tested artifacts, something like:
Terminology question: Implicit, Synthetic or Rule Task.
I prefer synthetic over implicit as it conveys for meaning for me. We
might say that task rules (usually) create synthetic tasks.
tested<TaskName> dependsOn <TaskName>, (test, check for this project
and all projects it depends on).
Which might turn out as a powerful alternative to enhancing the
command line. And it can be used from within the build scripts as well.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
