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.

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:
http://gradle.1045684.n5.nabble.com/Ideas-for-simplifying-the-bootstrapping-of-plugin-loading-td4588130.html#a4597841

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'

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') } }

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:
http://gradle.1045684.n5.nabble.com/Issue-with-Plugins-applying-other-Plugins-from-apply-from-script-td4982572.html

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!

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.