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

Old Forum
1

I’ve written a plugin over at https://github.com/huxi/huxi-gradle-plugins/tree/master/git-state-plugin

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

2

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?

3

The check is only supposed to be active in case of a release build. See https://github.com/huxi/lilith/blob/6677657bb4c9ce710d3dd2a95d61fd97fd64f7e8/config.gradle#L346 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 https://github.com/huxi/lilith/blob/6677657bb4c9ce710d3dd2a95d61fd97fd64f7e8/config.gradle#L382

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.