Is the new plugin extension approach the way to go?

(andrew.oberstar) #1

I was looking at the milestone 5 release notes and saw the new extension mechanism for plugins. Is the plan for this to replace the current convention support? Will the built in plugins be moving to this approach also?

We’re just about to begin our migration to Gradle, so I was wondering whether I should be updating our plugins to this approach now, to avoid future confusion.

(Adam Murdoch) #2

You should prefer the extension mechanism over the convention object mechanism. We will migrate the built-in plugins over time and new plugins will use the extension mechanism. The announce, ide, and c++ plugins all use extensions rather than convention objects.

However, the convention object mechanism is not going away any time soon. We will probably offer some migration mechanism, so that you can use both, and Gradle will warn the plugin users that they should use the new syntax for accessing the properties, rather than the new syntax.

(Benjamin Muschko) #3

Great, thanks for this information Adam. I believe the new extension mechanism won’t be backward-compatible in any kind of form right?

(Adam Murdoch) #4

Not yet. We’ll add some way to migrate from convention objects to extensions, so that a plugin can change to using an extension, but users don’t have to change their build scripts right away.

This will probably be some method on ExtensionContainer to register the extension as both a convention object and an extension. Gradle will then write a deprecation warning whenever the build script (or some other plugin) attempts to use the object via the convention mechanism.

So, if I have:

apply plugin: ‘my-plugin’

myPluginProperty = ‘some-value’

and I change ‘my-plugin’, the above will continue to work, but you get a warning reminding you to change your build script to:

apply plugin: ‘my-plugin’

myPlugin { myPluginProperty = ‘some-value’ }

In the meantime, if you have plugins which use the convention mechanism, it’s quite fine to keep using it. The convention mechanism will be supported for a long time. The plan is something like this: 1. Both mechanism supported. Recommend people use extensions. 2. Provide a migration mechanism so that existing plugins can start migration 3. Migrate the built-in plugins 4. After a reasonable migration period, deprecate convention objects 5. After another reasonable migration period, remove convention objects.

We’re still at step 1. You don’t have to do anything until we finish step 2.

(andrew.oberstar) #5

Thanks for the responses. That migration mechanism will be helpful.

(Peter Niederwieser) #6

I don’t see how the extension mechanism could ever replace the convention mechanism. As much as I like the former, dynamic mixins are an essential step towards an extensible object model, and I don’t want to see them go away.

(Adam Murdoch) #7

Maybe. Do you have an example of something you could solve with a convention object that you could not solve with an extension?