On 15/02/10 7:12 AM, Hans Dockter wrote:
Hi,
there is one very nice feature that should be simple to implement and
I would love to have it in 0.9.
Have a look at the following use case. Say you want to provide test
execution with and without coverage. There are many ways to implement
this. One very nice solution would be:
apply id: 'java'
task instrument << { ... }
task testWithCoverage(dependsOn: test) << { do the reporting }
test { dependsOn(task: instrument, requiredInDag: testWithCoverage }
The current alternative to the above is to have if conditions in the
task actions.
Thoughts?
This problem might be better solved by modelling the artifacts better.
By running 'gradle testWithCoverage' you are really saying 'I want the
coverage report'. Gradle should figure out that:
- testWithCoverage produces the coverage report. Its inputs are the
coverage data file and the source files.
- test produces the coverage data file when its inputs are the test
classes and the instrumented main classes.
- instrument produces the instrumented classes under test. Its inputs
are the main classes.
And wire the tasks up appropriately.
That is, we could abstract inputs and outputs somewhat, so that rather
than being just a set of files, they also have some semantic associated
with them. For example, the 'classes' task produces the 'main classes',
which happen to live in build/classes/main. The 'instrument' task
produces the 'instrumented main classes', which happen to live in
build/classes/instrumented (or wherever).
You could think of this as taking the source set concept (a set of files
with some semantic meaning) and generalising it.
We could then combine this with a rule that describe how to produce
artifacts with a given semantic value. For example, a rule which says:
when you need to produce 'instrumented nn classes', then create a
CoverageInstrument task, and set its inputs to 'nn classes'.
I think this would be a richer approach. Since you're reusing build
logic in the form of rules, rather than fixed task wirings, you can
easily stamp out the same behaviour for multiple different targets. eg
generate a separate coverage report when running the functional tests
against postgres, mysql, oracle, etc. Or generate a distribution for
each of java 1.4, java 1.5 and java 1.6. Or windows, linux and solaris.
This is especially useful when the classes are produced from a bunch of
different sources, such as generated source (antlr, web services, jaxb,
...) or compilers, or instrumenters. Gradle would take care of
dynamically creating and wiring together the tasks for each target.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
