Following BUILD-58 and BUILD-90, I (with the help of Atlassian folks, Google, and various colleagues, obviously) came to the conclusion that:

• Clover can't be entirely skipped using the <skip> configuration item; a lifecycle will always be forked, as soon as a Clover goal is registered in the build. See CLV-5796.
• So we need to push all Clover configuration into a profile to be able to isolate it.
• Profiles can only be activated by the presence of a file, system property (not pom property!), or manually (via the -P flag). (or depending on JDK or OS, but this is irrelevant here)
• The activation of a profile (i.e what file is used as the "trigger" for example) can not rely on pom properties either. (I tried doing <activation><file><exists>${fileToTriggerClover}, then have a pom property with a value of pom.xml - it would thus have been easy to change the value of that property to some non-existant file in projects where we want to skip Clover entirely. Does not work. Maven 3 seems to allow some properties to be used, like basedir, but that's about it.

Consequently, here's what I'm seeing as a practical solution:

• Declare a profile that enables Clover.
• On local dev builds, activate the profile manually (with -P).
• On build servers, the profile can be activated by a well known property provided by the build server, such as BUILD_NUMBER on Hudson.
• Configure the release plugin to activate this profile during releases. In fact, we already do this, and activate the existing release-perform-profile profile, which enforces usage of Maven 2.2.1. We can move this to a pom property, thus letting each project configure their releaseProfiles list: release-perform-profile,enable-clover will be the default.