[email protected] wrote:
Over the past week, I've had a bunch of ideas for enhancing
the Gradle's command line.
My goals are as follows:
[1] Allow directory and/or file tasks to be specified naturally on
the command line, without any weird clutter. They should't
be second-class citizens in a world where Gradle one day
handles C++ builds.
[2] Make it easy to specify a list of tasks within different
namespaces (subprojects), and which tasks in the list
to execute (or exclude) recursively.
[3] Provide a simple rule for resolving conflicts in whether to
run a task or not in a convenient, expressive, and
well-defined way.
[4] Allow tasks to be specified (or skipped) by regex.
[5] Provide a syntax for skipping any task that depends upon
a given task (or task regex) directly or indirectly.
[6] Provide a way to tunnel a set of args to a task via the
command line.
clipped...
I have found that more often than wanting control over recursion /
non-recursion of subprojects, I want control over project dependencies.
For example, in a large multiproject build, I may build the entire
project once, to get all the dependencies resolved, but then spend a
long time doing development in a single subproject. I want to compile
and test that module, but not all the dependent ones. With the current
task path syntax of :projectPath:test, all the tasks needed to build the
dependent projects (including running their tests) are re-run each time.
I would like to be able to do something like append a '!' character to
mean, just this one, without dependencies. This could go in the project
path portion of the task path or after the task.
For example - in a two project system (consumer, provider subprojects
with java plugin), consumer depends on provider:
gradle :consumer:test
The current syntax will run full lifecycle (init-libs) on provider
before init-test of consumer just as it does today.
gradle :consumer!:test
This would only run init-test tasks on consumer project (ignoring all
task dependencies on other projects)
gradle :consumer!:test!
This would run only the test task only on the consumer project (ignoring
all task dependencies).
Even in a single project build it could be helpful to just do
gradle testCompile! test!
to just recompile and run the tests without all the rest of the
dependent tasks.
This seems to me to be a good way to handle the requirements of Jira
GRADLE-220
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
