[GRADLE-2402] Code quality plugins require depenencies in project repositories Created: 26/Jul/12 Updated: 10/Feb/17 Resolved: 10/Feb/17
The general pattern of the codequality plugins is to create a configuration for itself in the project, then pull a dependency from that configuration. Since the configuration is in the project directly, that dependency is needs to be the project's repositories. This is contrary to how plugin dependencies typically work, which is to pull from the buildscript repositories. Here's an example line from FindBugsPlugin.groovy:
Should be fixed:
Ideally I should be able to connect the findbugs configuration to a specific repositories and not the default chain, so that I can separate plugin dependencies from code dependencies, which I could do with Ant/Ivy.
|Comment by Peter Niederwieser [ 27/Jul/12 ]|
ad 1. I'm not sure if this should be the default, as for many users the current behavior is more convenient. Currently, the defined purpose of `buildscript` is to put dependencies on the build script class path, which isn't necessary/desirable for dependencies like FindBugs. I think the solution for your requirement would be to support a tighter coupling between dependencies and repositories (as a generic feature).
ad 2. We don't want to add dependencies like FindBugs to the Gradle distribution because 1. they would seriously increase the size of the distribution 2. many people don't need them 2. we can't tell which version users want to use. Actually, earlier versions of the code quality plugins did bundle (and hardcode) their dependencies, and we got many requests to change that. If it is important for you to bundle these dependencies, you could create a custom Gradle distribution.
ad 3. Agreed. We should document which dependency each plugin pulls by default.
|Comment by Benjamin Muschko [ 15/Nov/16 ]|
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.
We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.
Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!
|Comment by Benjamin Muschko [ 10/Feb/17 ]|
Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.