[GRADLE-2402] Code quality plugins require depenencies in project repositories Created: 26/Jul/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.1-rc-2
Fix Version/s: None

Type: Improvement
Reporter: Justin Ryan Assignee: Unassigned
Resolution: Won't Fix Votes: 0


 Description   

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:

project.dependencies {
    findbugs("com.google.code.findbugs:findbugs:$extension.toolVersion")
}

Should be fixed:

  1. Plugins should always pull from buildscript repositories
  2. Built-in plugins should have all needed dependencies in the gradle distribution, like other embedded features
  3. Plugins should document their required dependencies, since they currently have to be manually added to the repositories (when not using a broad Maven Central repo)

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.

 Comments   
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:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

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.

Generated at Wed Jun 30 12:20:56 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.