On 11/04/2012, at 10:05 AM, Eric Berry wrote:
> Is there a proper way to create plugins for Gradle yet? Pre M3 I could just
> install a jar file under the lib/plugins directory and that was it.
The 'proper' way has always been to use the buildscript { } section to declare
a dependency on the plugin:
buildscript {
repositories { someRepo() }
dependencies { classpath 'some:plugin:1.2' }
}
apply plugin: 'some-plugin'
Putting the jars in lib/plugins has never been a supported or recommended way
of making plugins available, as it leads to non-reproducable builds, where the
output of the build depends on which version of the plugin you happen to have
installed into the distribution, if any. It means extra manual work to set up a
development environment, and extra work to keep all the developer and CI
machines up to date. It means a developer cannot work on multiple versions of
the software on the same machine, and a CI server cannot build multiple
versions of the software. It means you can't use the wrapper. In short, we
don't think it's a good idea.
Nevertheless, if you really want to be able to put jars in this directory, you
can use a regular file dependency to do this:
buildscript {
dependencies {
classpath fileTree(dir: "$gradle.gradleHomeDir/lib/plugins", include:
"*.jar")
}
}
>
> Now it looks like we are supposed to be using "apply from" scripts, but my
> co-workers keep running into odd problems with cache, or 301 redirects.
>
> It's really annoying, and it's making it very hard to keep justifying our use
> of Gradle.
>
> I really like Gradle - it's simplified my life and it made my job of setting
> up a common build environment/settings, etc... very easy. However, it seems
> that the area of plugins has been somewhat neglected in recent releases of
> Gradle and I'd like to know when we can expect some level of solidification
> on the subject. Otherwise, I'll probably be forced to switch all our Java
> projects to Maven 2, and I highly doubt there will be any movement back to
> Gradle once that's done.
>
> Plugins should be easy to implement, and easy to use. This was the case with
> M3, but in my opinion, it seems to be quickly slipping into the "not so much"
> area.
>
> Ex. This was great:
> apply plugin: "chegg-corp"
>
> Which worked with M3 by installing the chegg-corp.jar file into the
> lib/plugins directory.
You should instead publish chegg-corp.jar to your repository (or wherever it is
all your other dependencies live), and use something like:
buildscript {
repositories { theCorporateRepo() }
dependencies { classpath 'chegg-corp:chegg-corp:1.2' }
}
apply plugin 'chegg-corp'
You should find this ends up being much less work than trying to get the right
version of chegg-corp.jar into the right places on all the machines that need
it.
> Post M3, that didn't work anymore and was replaced with "apply from" scripts.
>
> Ex. This is acceptable:
> apply from:
> "http://internal.host/gradle-plugins/installation/chegg-corp.groovy";
>
> However, this worked for a while until M8/M8a/M9, where it now works "most of
> the time". We are seeing some issues when there's a 301 redirect here, or if
> any dependency jars downloaded by these scripts get's updated.
> http://issues.gradle.org/browse/GRADLE-1210
>
> It's also not that easy to implement this solution because of at least one
> outstanding bug:
> http://issues.gradle.org/browse/GRADLE-1517
> http://issues.gradle.org/browse/GRADLE-2136 (think this is a duplicate of the
> one above)
>
> This caused some weird, but necessary code adjustments to our plugin's "apply
> from" scripts. Ex. it's now necessary to check to see if the plugin is
> applied before applying it otherwise Gradle errors out saying that the plugin
> is already installed.
> Eg:
> buildscript {
> repositories {
> ivy {
> name = 'gradle_templates'
> artifactPattern
> "http://launchpad.net/[organization]/trunk/[revision]/+download/[artifact]-[revision].jar";
> }
> }
> dependencies {
> classpath 'gradle-templates:templates:1.2'
> }
> }
> // Check to make sure templates.TemplatesPlugin isn't already added.
> if (!project.plugins.findPlugin(templates.TemplatesPlugin)) {
> project.apply(plugin: templates.TemplatesPlugin)
> }
>
> The last option really is to copy the above code into their own build scripts
> for each of the plugins they want to include, and this is NOT acceptable to
> me.
>
> My question then is this. Are plugins going to be ironed out for Gradle 1.0,
> and if so, how long before we can expect 1.0?
>
> Looking through the roadmap, I know there's a discussion going on (that I've
> participated in) regarding this:
> http://forums.gradle.org/gradle/topics/plugin_portal_improving_plugin_development
>
> But that page says it's not planned until after 1.0. Is that correct?
It is. You should find that by publishing your plugin jar to a repository and
declaring a buildscipt { } dependency on that published jar things will work
fine.
Of course, there are things we can do to improve all this. After 1.0 is out, we
will look at simplifying things, so that you need less boilerplate to apply a
plugin, to fix the above jira issues, to make script plugins work as well as
jar plugins, and so on.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
