[GRADLE-1795] M5: Plugins installed in [gradle_home]/lib/plugins not included in classpath. Created: 14/Sep/11  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-5
Fix Version/s: None

Type: Bug
Reporter: Eric Berry Assignee: Unassigned
Resolution: Won't Fix Votes: 0


I have some custom plugins that I've installed into [gradle_home]/lib/plugins. These plugins no longer seem to be included in the classpath.

Existing projects that had "apply plugin: 'my_company_plugin'" no longer work.

I've double checked and made sure that the company plugin.jar file is in the lib/plugins dir for the new M5 install.

Comment by Adam Murdoch [ 14/Sep/11 ]

This was an intentional change. We believe that modifying the installed Gradle distribution is generally not a good approach:

  • You end up with unreproducible builds, where a build works on one machine and not others.
  • You can't use the Gradle wrapper to manage the Gradle version that your build uses.
  • You need to do extra work to provision a new build machine (for developer or CI or whatever purpose).

Instead, we'd rather you declare the plugins that you need in your build, or your build infrastructure.

Perhaps you could give us some details about the approach that you're using and the problems you're trying to solve. There might be some other, supported, method you can use instead of installing the plugins into $gradleHome/lib/plugins. Or, there might be some improvement to DSL we can make, so that it's easier for you to declare these plugins in your build.

Comment by Eric Berry [ 14/Sep/11 ]

Sure. I use the plugin jar file to provide common setup for my company's many projects.

I described the usecases and need in an earlier mailing list discussion:

At one point I had suggested a dsl change that would allow projects to have something like this in their build.gradle files:
apply jar: 'http://host/to/corp-plugin.jar', plugin: 'corp-plugin'

Comment by Blaine Simpson [ 15/Nov/11 ]

The automatic network retrieval idea from Eric is nice.

But regarding a replacement for the $gradleHome/lib/plugins behavior that is the original topic of this issue, I think the following is more than satisfactory:

buildscript { dependencies { classpath fileTree(dir: 'd:/sharedplugins') } }
Comment by Eric Berry [ 15/Nov/11 ]

I suppose that would work, and I could still use gradle_home so that it's platform independent. I would want to be able to have that buildscript snippet in an 'apply from' script and I'm having other issues with Plugins and 'apply from' scripts that this doesn't solve:

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:04:33 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.