Since long ago, there have been two kinds of plugins: script plugins and
binary plugins. Script plugins are simply build scripts that get applied
with "apply from:". Binary plugins are classes that implement the Plugin
interface and get applied with "apply plugin:". The latter are typically
distributed as a Jar and brought in via Gradle's dependency management. To
my knowledge, putting the Jar into lib/plugins was never officially
supported. (Personally, I like the idea of supporting a special directory
(other than lib/plugins) where external plugins can be dropped. This could,
for example, make sense for companies which want to assemble their own
Gradle distribution.)
Script plugins currently have some limitations. For example, the scripts
aren't cached yet. Binary plugins require a bit more effort but are rock
solid.
If you decide to go with binary plugins, you'll have to publish them to a
place (shared file system, Maven/Ivy repo) from where they can be fetched
using Gradle's dependency management. Plugins that have external
dependencies will need to include a pom.xml or ivy.xml. Since plugins are
built with Gradle anyway, all of this is fairly easy to do.
On the build side, all that is needed is one buildscript {} block in the
root build script with repository and dependency declarations. Given that
similar code is needed for regular dependency management, this might be
perceived as a few lines of code duplication. However, the build script
section is only needed once per build (not per project!), it's there for
good reasons (many people don't understand the challenge), and I can't see
it causing real problems. If you need to bring in third-party plugins from
many different repositories, a repository manager like Artifactory or Nexus
can offer them all via one virtual repository, further simplifying build
script configuration.
Gradle 1.0 is close; it might see some more bug fixes related to plugins,
but don't expect new features. As you may know already, it is a high
priority for post-1.0 to make writing, testing, hosting, distributing, and
referencing plugins easier.
I hope this answers your questions. If you think you've found a critical
issue that should be fixed for 1.0, please raise it in the forum, and
provide as much information as you can (or even a pull request). If an issue
doesn't make it into 1.0, it's not the end of the world; we will continue to
publish frequent releases after 1.0.
--
Peter Niederwieser
Principal Engineer, Gradleware
http://gradleware.com
Creator, Spock Framework
http://spockframework.org
Twitter: @pniederw
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Proper-way-to-do-plugins-tp5631476p5631602.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
