Awesome.
For the sake of the discussion here I want to dive deeper into a core
aspect this specs solves very well:
- Enable Gradle core plugins to be downloaded on demand.
- Respect the fact that versions of those core plugins have a 1:1 mapping
to the Gradle runtime version. The Gradle runtime and the Gradle core
plugins form a releasable unit regardless of whether they are physically
part of one distribution or not. A single version number for a Gradle
runtime should fully determine the behavior of this distribution (which
included the core plugins). It is not our goal to fix and redistribute
single core plugins. That way the Gradle runtime can guarantee a very well
tested set of core plugins that play well with each other. If we allow for
arbitrary combinations of the core plugins, it will be much harder to
guarantee this. Additionally it will also be much harder for a user to
figure out the capabilities and fixes of a particular Gradle runtime if we
allow for arbitrary combinations of core plugins.
Anything you would like to add here, Adam?
Possibly also a repository that uses mappings rules provided by the build.
> This would allow, for example, for a build to say things like: map plugin
> name 'x' to this Gradle script, or this implementation module, or this
> implementation Class instance.
I love the use case for the script plugins. I have seen many large projects
with a single build (e.g. a 900 submodule build), where most of their
plugins are scripts in the root directory. Being able to define such a
mapping will:
- Make it more convenient to apply it
- Make it more expressive
- Make it much more stable (e.g. you can change the directory, you can move
scripts plugins into repositories, and your build script would still work).
It would make it easy to auto-apply script plugins from the command line
(once we have the generic mechanism :)). Such a mapping might also allow to
define a releasable unit for the organization specific extensions similar
to what we do for the core plugins, even in the case when you are using
binary plugins.
Search for plugin with the given name in the Gradle runtime's mappings. If
> found, verify that the implementation meets the version criteria.
> Search for plugin with the given name in the search classpath. If found,
> verify that the implementation meets the version criteria.
What use case do you see for a _versioned plugin_ to be looked up in those
repos. Why not just skip those repos versioned plugins?
Note that the classes from the plugin are not made visible to any script.
Just to point it out for the sake of the discussion here. I really like
that we use new mechanism for providing a better way to deal with the
classpath. This will be fully backwards compatible as if you apply a plugin
with the current mechanism, this will still work the same way as it does
now. With the core plugins this is different though (as you pointed out in
the open issues).
I want to make sure that I fully understand the purpose of the require
clause, vs. using the standard buildscript{} DSL . Here is how I see it: It
reflects that we are applying a platform specific element to the
buildscript classpath. That way we do additional checks regarding
compatibility, make assumptions about default locations and possibly expect
some logical packaging that let us distinguish between API and
implementation.
The initial driver in my opinion should be the use cases that make it
easier to work with external plugins. Making the Gradle core plugins
distributable I see as a second step.
Hans
On Thu, Aug 8, 2013 at 5:32 PM, Adam Murdoch <adam.murd...@gradleware.com>wrote:
> Hi,
>
> There's a rough draft for how we might improve our plugin mechanism to
> make it easier to share plugins within the Gradle community (and other
> improvements) here:
> https://github.com/gradle/gradle/blob/master/design-docs/publishing-and-sharing-plugins.md
>
> Feedback appreciated.
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
>
>
