Is it considered good practice for third-party plugins to automatically attach functionality to the build lifecycle?

I’ve written a plugin over at

That plugin attaches a ‘checkGitState’ task to the project it is applied to. This task makes sure that the git repository is in a clean state, i.e. it makes the build fail if there are new or modified files. There is an additional extension property to enable that check.

Would it be a desired best-practice to let an existing task, like ‘check’, automatically depend on that task? I currently leave this to the user of the plugin but that feels kind of un-gradle.

Gradle 1.0-milestone-9

Gradle build time: Tuesday, March 13, 2012 4:10:09 PM UTC

Groovy: 1.8.6

Ant: Apache Ant™ version 1.8.2 compiled on December 20 2010

Ivy: 2.2.0

JVM: 1.6.0_29 (Apple Inc. 20.4-b02-402)

OS: Mac OS X 10.7.3 x86_64

If the check has its own task (‘checkGitState’), and that task is not currently attached to the lifecycle, then what is the purpose of the extension property that enables the check?

The check is only supposed to be active in case of a release build. See for an example. In this case, the property wouldn’t really be needed since I only add the dependsOn in that same case. It is mostly a preparation for a possible automatic “check.dependsOn ‘checkGitState’” in the future.

The plugin does also create a project.ext.gitHeadHash property that contains the git revision of the current git HEAD. It is supposed to be used to expand variables like in

The idea is that one know with 100% certainty which revision was used while building a piece of software.

But I’m not really happy with the manual way it is attached right now. So I wondered what you think about this issue.