-
Suggestion
-
Resolution: Fixed
-
None
Problem:
Bamboo Clover Plugin allows to automatically integrate Clover with a Grails project. It uses a standard 'grails install-plugin' command to add Clover Grails Plugin to the project. This method is deprecated, however, as since Grails 1.3 it's possible to install plugin via dependency declaration in BuildConfig.groovy file.
Thus, for Clover-enabled projects a following warning is present in a log file:
Warning The install-plugin command is deprecated and may be removed from a future version of Grails. Plugin dependencies should be expressed in grails-app/conf/BuildConfig.groovy. See http://grails.org/doc/2.2.x/guide/conf.html#pluginDependencies.
Possible solution:
Instead of 'grails install-plugin' modify content of the BuildConfig.groovy file on the fly and add 'clover' plugin dependency.
Traps: 
- grails 1.2.x and older versions do not support this new way
- you're modifying the original source ... keep a copy of original file?
It has a low priority as 'install-plugin' is still supported but just deprecated.
[BAM-13404] Use BuildConfig's DSL to install Clover plugin
Update: the latest Grails 2.3.5 blocked a possibility to install plug-ins using the install-plugin command.
grails install-plugin clover
| Warning
Since Grails 2.3, it is no longer possible to install plugins using the install-plugin command.
Plugins must be declared in the grails-app/conf/BuildConfig.groovy file.
Example:
grails.project.dependency.resolution = {
...
plugins {
compile ":clover:3.2.2"
}
}
Additionally, add these custom repositories to the "repositories" block:
https://maven.atlassian.com/public/
https://maven.atlassian.com/public-snapshot/
mavenCentral()
As a consequence, Clover does not run at all.
Workaround:
Use manual Clover integration, instead of the automatic one provided by a Bamboo Clover Plugin.
Plan how to fix this:
BAM-15085)Thanks to this, scope of an automatic integration will be reduced to a single GrailsBuildTask. The GrailsPreBuildAction (calling the 'grails install-plugin' command) will become obsolete. This will also protect us against accidental workspace conflicts during checkout / committing tags etc ... in subsequent tasks or builds (as changes will be reverted each time, even for a failed tasks).