Hi, we want to exclude the commons-logging dependecy in our project and use the following closure:
// exclude commons-logging due to re-routing
configurations.all {
exclude group: 'commons-logging'
}
but if we build it with the nightly build of gradle (gradle-1.0-milestone-8-20120207000059+0100) we get an error saying that checkstyleMain task needs the commons-logging dependency. Therefore we use this closure now:
// exclude commons-logging due to re-routing
configurations.all { Configuration c ->
if(!c.name.equals('checkstyle'))
exclude group: 'commons-logging'
}
Shouldn’t it be possible to modify configurations of plugins? Aren’t the dependencies managed in the buildscript of the checkstyle plugin itself?
The new plugin allows the user to control the checkstyle classpath, part of which is the checkstyle tool itself. This allows you to specify which ever version of checkstyle you like.
I think you have a point. It can be quite surprising that when, say, the ‘checkstyle’ plugin is used, ‘configurations.all’ suddenly includes the ‘checkstyle’ configuration. Maybe the code quality plugins shouldn’t add regular configurations but should allow to declare tool dependencies in a different way (e.g. ‘checkstyle { toolDependencies … }’). Actually that’s something we recently discussed. On the other hand, it’s currently a common thing for (not just the code quality) plugins to add their own tooling configurations. Opinions?
I think a good solution would be to declare tool dependencies in a different way (e.g. checkstyle { toolDependencies … }) such that the tool configurations doesn’t interfere with the project ones.