Given:
- Gradle now has support for Junit and TestNG
- Gradle will someday support builds for code written in C/C++
- Some 'test' targets may end up being used for non-JVM languages (e.g.: C/C++)
- Gradle may provide richer support for fancy production runtime configs (not just test runtime configs)
It seems like the original meaning of the 'test' target needs to be abandoned in favor of more specific targets;
the useJunit() and useTestNG() functions within 'test' feel like a kludge to work around the current ambiguity.
Hence, we could have specfiic top-level target like this:
Run junit task (which runs junit tests)
% gradle junit
Run testng task (which runs testng tests)
% gradle testng
If someone wants a 'test' target, they can make one easily enough:
createTask("test", dependsOn: "junit")
If someone wanted to run a java program in a non-test mode
and do something like: "java -cp $runtime.asPath() blabla".execute(),
we could have a 'java' task:
% gradle java
If someone wanted to run a java-based task more abstractly, they could
do something like this:
createTask("run", dependsOn: "java")
That way, gradle could be used to "run" c++ code and java code...
or whatever else you'd like in a non-test config too (and do so
on a project-by-project basis).
It would be interesting to see what thoughts folks have on the
mailing list; hopefully we can use JIRA to track the issue once
some consensus is reached & lurking issues are flushed out
(such as what this means for the build dir structure and the
default include/exclude patterns). 