#36 Custom filters for finding .class files to instrument

[Lasse Koskela]

This patch adds the ability to InstrumentTask to filter
the selected FileSets further by defining a sequence of
custom filters in the body of the task.

Usage of this feature looks like the following:

<cobertura-instrument
datafile="${build.dir}/cobertura.ser"
todir="${build.instrumented.dir}">
<fileset dir="${build.classes.dir}">
<include name="**/*.class" />
<exclude name="**/*Test.class" />
</fileset>
<fileset dir="${build.otherclasses.dir}">
<include name="**/*.class" />
<exclude name="**/*Test.class" />
</fileset>
<filters>
<!-- this is our custom filter right here -->
<source-modified-since timestamp="2006-03-06
11:00:00" />
</filters>
</cobertura-instrument>

Adding new custom filters is a matter of taskdef'ing
the element name (e.g. "source-modified-since") into
the implementation class. The implementation class must
implement java.io.FileFilter which includes exactly one
method:

public interface FileFilter {
boolean accept(String filepath);
}

The patch includes an example implementation of such a
custom task, named SourceModifiedSince, which filters
selected .class files based on whether the project
contains a matching .java file that has been touched
since the specified date.

[Mark Doliner]

Logged In: YES
user_id=20979

This is kind of cool. In what circumstances would you use
the source-modified-since task?

[Lasse Koskela]

Logged In: YES
user_id=845101

The inspiration for the source-modified-since filter came
from a certain client's management push towards higher test
coverage. As a result, someone asked me if I had any ideas
regarding how to measure test coverage only for "new code"
because it would be easier to define coverage goals "from
now on" rather than take into consideration the huge amount
of legacy code without tests.

I've been actually meaning to split the original patch file
into two: one for the filtering capability in general and
one for the source-modified-since filter. Do you think that
would be a good idea? I actually added the ability to
explicitly specify source paths for the
source-modified-filter last week so a new patch is coming
soon anyway. (not right now, though, since I should be
packing stuff--I'm moving house this weekend)

From your comment, I interpret that you consider the filter
stuff in general being a candidate for inclusion but what
about the source-modified-since filter?

[Mark Doliner]

Logged In: YES
user_id=20979

I still haven't looked at the patch, but I think I'd be
willing to accept both parts. I'm not sure very many people
would use it, but it doesn't get in the way so it shouldn't
cause problems.

I would keep everything as one patch--if I accept the filter
stuff in general then I'll accept the soure-modified-since
filter so that people have an example. And I guess I'll
wait for an updated patch from you (I'm a little busy right
now, too :-) )

I hope your move goes well!

[Lasse Koskela]

Logged In: YES
user_id=845101

Alright. Here's the new patch supporting a nested source
path description (versus the default, implicit "anywhere
under the working directory" source path).

The usage would now look like this:
<source-modified-since timestamp="2006-01-01 00:00:00">
<path>
<pathelement location="${first.src.dir}"/>
<pathelement location="${second.src.dir}"/>
</path>
</source-modified-since>

[Lasse Koskela]

Logged In: YES
user_id=845101

A slight addition--since the SourceModifiedSince filter is
going in as an "example", I added its taskdef stuff into
tasks.properties as well.

[Lasse Koskela]

Patch adding extra custom filtering capability to InstrumentTask and an example filter implementation for instrumenting only "source modified since X"

[Lasse Koskela]

Logged In: YES
user_id=845101

Uploading an updated patch that was tested against trunk
checked out at 2006-04-10 at 11:40 GMT.

[Lasse Koskela]

Patch updated (removed some extraneous cruft) and tested against TRUNK on April 10th, checked out at 11:40 (GMT)