On 09/08/2013, at 12:49 PM, Hans Dockter <hans.dock...@gradleware.com> wrote:
> 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?
Only that the approach doesn't rule out later supporting multiple combinations
of Gradle runtime version and some core plugin version, if we find a good use
case.
>
> 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.
Exactly right. The idea is that you can use it to define your own logical
'distribution' of runtime and plugins without bundling them all physically into
a single zip, and that this distribution may or may not include some core
Gradle plugins or some community plugins or some of your own 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?
There are a few reasons:
- Conflict handling. You don't want one version of a plugin on your build
script classpath and another, incompatible, version applied to the project.
Which makes me think the spec is not quite right wrt dealing with plugins found
on the classpath.
- To enforce the 1-to-1 mapping of Gradle runtime and core plugin version.
- To allow us to transition a plugin out of the distribution. We'd start off by
deprecating the mapping, so that you have to declare the version when you apply
the plugin, even though it's still potentially coming from the distribution.
Later, we'd remove the mapping.
- For consistency with dependency resolution elsewhere.
>
> 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.
It's really just a different syntax so we can fix a few things that aren't
quite right with the script class paths now:
1. Only the API of the plugin is made available. Its implementation is hidden
from the script. The plugin's dependencies are not shared with anything.
2. The implementation classes for a plugin with a given id is loaded once and
shared across all scripts that reference it.
3. The plugin classes are not inherited by any other scripts.
4. The dependency is declared based on the plugin's identifier, not the
identifier of the module it is packaged in.
5. There's a little less boiler plate.
One implication of #1, #2 and #3 is that a project is no longer coupled to a
parent project through the inherited classpath. If they happen to require the
same plugin, they'll get the same copy of it.
>
>
> 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.
Absolutely.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
