Java – Configuring clover exclude file patterns

antcloverjava

Greetings,

I have clover 3.0 setup using ant, with the following file exclusions:

<clover-setup initString="${clover.initstring}" flushpolicy="threaded" flushinterval="30000">
    <methodContext name="tostring" regexp="(.* )?public String toString\(.*\).*" />
    <files>
        <exclude name="**/*Test.java" />
        <exclude name="**/entity/fields/*.java" />
    </files>
</clover-setup>

The *Test files are excluded correctly, as is the toString() calls, the files under the entity/fields package are not. Does the <files> ant type work with two excludes items? Can you have a partial package definition on your exclude name? I used **/..... format as the doc says something cryptic like

An Ant patternset, relative to the top level package (e.g. com/cenqua/clovertest), element which controls which files are included or excluded from Clover instrumentation. Use this when you wish to exclude files based on packages.

From this I read it starts at clovertest in the sample, although i'm not sure how it knows what the top level package is? Is that the first package with files?

As an example my java classes that i want to exclude are like

package com.acme.missileinabox.common.entity.fields;

public class ActivityFields {
   ....
}

Any idea what i'm foobaring? I posted the question here with no response.

Best Solution

You may need to specify a <fileset>, possibly containing one or more <patternset>'s, as discussed under the <fileset> topic in <clover-setup>.

Addendum: If you change <files> to <fileset>, you can use the latter's implicit <patternset> unchanged:

<fileset>
    <exclude name="**/*Test.java" />
    <exclude name="**/entity/fields/*.java" />
</fileset>

Alternatively, use <files> and nest an explicit <patternset>:

<files>
    <patternset>
        <exclude name="**/*Test.java" />
        <exclude name="**/entity/fields/*.java" />
    </patternset>
</files>

Related Solutions

Java: Multiple class declarations in one file

javac doesn't actively prohibit this, but it does have a limitation that pretty much means that you'd never want to refer to a top-level class from another file unless it has the same name as the file it's in.

Suppose you have two files, Foo.java and Bar.java.

Foo.java contains:

public class Foo

Bar.java contains:

public class Bar
class Baz

Let's also say that all of the classes are in the same package (and the files are in the same directory).

What happens if Foo.java refers to Baz but not Bar and we try to compile Foo.java? The compilation fails with an error like this:

Foo.java:2: cannot find symbol
symbol  : class Baz
location: class Foo
  private Baz baz;
          ^
1 error

This makes sense if you think about it. If Foo.java refers to Baz, but there is no Baz.java (or Baz.class), how can javac know what source file to look in?

If you instead tell javac to compile Foo.java and Bar.java at the same time, or if you had previously compiled Bar.java (leaving the Baz.class where javac can find it), or even if Foo.java happens to refer to Bar in addition to Baz, then this error goes away. This makes your build process feel very unreliable and flaky, however.

Because the actual limitation, which is more like "don't refer to a top-level class from another file unless it either has the same name as the file it's in or you're also referring to another class that's named the same thing as that file that's also in that file" is kind of hard to follow, people usually go with the much more straightforward (though stricter) convention of just putting one top-level class in each file. This is also better if you ever change your mind about whether a class should be public or not.

Newer versions of javac can also produce a warning in this situation with -Xlint:all:

auxiliary class Baz in ./Bar.java should not be accessed from outside its own source file

Sometimes there really is a good reason why everybody does something in a particular way.

Java – How to create a file and write to it

Note that each of the code samples below may throw IOException. Try/catch/finally blocks have been omitted for brevity. See this tutorial for information about exception handling.

Note that each of the code samples below will overwrite the file if it already exists

Creating a text file:

PrintWriter writer = new PrintWriter("the-file-name.txt", "UTF-8");
writer.println("The first line");
writer.println("The second line");
writer.close();

Creating a binary file:

byte data[] = ...
FileOutputStream out = new FileOutputStream("the-file-name");
out.write(data);
out.close();

Java 7+ users can use the Files class to write to files: