The solution is still ant-glob-pattern - oriented.
Changing (optionally) to more project-tree oriented needs a separate JIRA

Following stuff needs to be added:

• mark just-excluded files as dirty instead of scheduling immediate rebuild
• right-click action for module exclusion
• add exclude action to Coverage Explorer View

Created CIJ-301 for excluding 100% covered classes from the view only

I should have deleted my last comment above, instead of just UPDATING it.

What is the purpose of excluding 100% covered classes?

To remove them from the Coverage Explorer, so a testing session can focus on just a few dedicated classes or packages. On clarification with Kate however, she doesn't actually want to exclude them from Clover. So ignore that. Also, she can sort the files in the CoverageExplorer to achieve mostly what she wants.

Maybe this should be done automatically?

Nope. Don't worry about it.

The includes/excludes in the Package Explorer is awesome! Kate == very excited!

There is still value in having the context menus, BTW.

I mean, if it can be done in the normal Project Explorer it's probably good to do it in the Coverage Explorer too even if it's not how Kate does it.

Requirements gathering FAIL (not directed at anyone in particular). This issue seems to have started out as "exclude from instrumentation" and is now including "exclude in Coverage Explorer if condition X is met". Better we caught this now than later, of course.

I think I misunderstood. Are you saying that there's still value in the context menus but just not in the Coverage Explorer?

Exclusion for instrumentation shouldn't be necessary just for certain classes of, er, classes being excluded / included in the Coverage Explorer. Clover-for-Eclipse will filter out classes with 100% coverage via a toggle button in the toolbar. I suggest you do it that way.

Can I suggest that the grey Clover icon might be less laden with meaning than the red icon?

What is the purpose of excluding 100% covered classes?
Maybe this should be done automatically?

UPDATE Kate has just mentioned that this is not how she would use it. So don't bother adding the menu to the Coverage Explorer just yet.

Another valid use-case however, (one which Kate in fact would use), is to toggle includes/excludes in the Coverage Explorer panel as well:

During a testing session, Kate likes to exclude classes based on how much coverage they have. e.g. she likes to exclude classes which have coverage of 100% already.
The decision to exclude a class is most often made when viewing the coverage explorer.

Also - this may be a known bug, basically, if you select "Add includes" on a directory which is already marked as included, the icon changes to red.
The includes/excludes patterns are still correct though.

Slawek - this new feature is looking excellent! Great work!

We could probably tighten up the wording a little on the actual excludes/includes context menu:

For a directory context menu, we probably don't need the non-recursive option?
We could just have the following options, worded like so:

• Include all files in: com/cenqua/clover/types
• Exclude all files: com/cenqua/clover/types

  ---

• Edit Settings

Both of which would add the com/cenqua/clover/types/** includes/excludes pattern.

For a single file, you would then have:

• Include file: com/cenqua/clover/types/Clover.java
• Exclude file: com/cenqua/clover/types/Clover.java

  ---

• Edit Settings

When a user is looking at that menu, they don't really want to think about Ant Globs. Having the Edit Settings item at the bottom, then gives them a very easy way to go in and tweak the excludes/includes if need be.

Kate - we will get you a version to try ASAP with these simplifications made.

P.S. By making all includes/excludes recursive, we wouldn't to do deal with this case:

By looking at the unexpanded tree, you can't see that the remote package is actually included.

Slawek - what can be done in the plugin to alleviate the pain when it comes to including/excluding files/packages/modules for instrumentation?

What if the coverage view provided a way for users to select files/packages for inclusion and exclusion?
It would mean a full build with Clover is required, and then another clean build after a file/package was selected however, but would be a lot more user friendly than the current wild-card approach.

I'm currently struggling trying to configure excludes via IDEA. I've even managed to get the "please rebuild database" error in trying to get it to work.

Even an example in the Clover docs would be good. I'm just trying to exclude a single package from being instrumented.

Also, after excludes are modified and rebuild is done, the clover database should also be deleted and regenerated.

Also, make it possible to exclude entire Modules from Clover instrumentation.

Something I just noticed is that the Clover plugin does not respect the excluded files in the Compiler configuration of IDEA.
This for instance causes the Clover build itself to fail, because the PluginVersionInfo.in files is attempted to be compiled.