Migrating to qualified plugin ids.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Migrating to qualified plugin ids.

Luke Daley-2
Hi,

One thing I haven’t quite worked out is how to handle the migration to qualified plugin ids, for non core plugins.

In order for plugins to be resolvable via the central plugin service, they must have a qualified id. This means that authors will have to publish a new version. The question is whether we encourage authors to move to exclusively qualified ids, or if they support both for a time.

All plugins initially available via the central plugin service can be used via the old (i.e. buildscript {}) and new (i.e. plugins {}) mechanisms. One catch being that the ID has to be qualified to work via `plugins {}`.

Options:

1. Encourage authors to publish new versions of their plugins with qualified ids
2. Encourage authors to publish new versions of their plugins with an additional qualified id

For #2, the author would just add another META-INF/gradle-plugins/«qualified id».properties file to their implementation jar. This effectively means that the plugin jar contains two plugins, that happen to be implemented by the same class. 

The issue with #1 is that users of the new version will have to change their apply(plugin: «id») statements to use the new qualified id.

The issue with #2 is that it’s potentially more confusing, and we’d probably have to prevent double application of the plugin (once via qualified, once via unqualified).

I’m inclined to go with #1 as I don’t think this will be onerous in practice, and will make qualified ids more pervasive quicker.

Thoughts?

— 

Luke Daley
Gradleware
Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
Reply | Threaded
Open this post in threaded view
|

Re: Migrating to qualified plugin ids.

pledbrook
> The issue with #1 is that users of the new version will have to change their
> apply(plugin: «id») statements to use the new qualified id.

I prefer this approach as long as it's combined with appropriate
feedback. Mentioning this in the release notes is important, but would
it be possible to add a check when the build is executed? I'm thinking
along the lines of, if no qualified ID is present in the apply()
statement, then:

1. warn that the user may have to update the ID

2. check whether the plugin repository contains a plugin of the same
name, but with a qualified ID and let the user know that such is
available.

Peter

--
Peter Ledbrook
t: @pledbrook

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Migrating to qualified plugin ids.

Luke Daley-2


On 11 June 2014 at 3:33:35 am, Peter Ledbrook ([hidden email]) wrote:

> The issue with #1 is that users of the new version will have to change their 
> apply(plugin: «id») statements to use the new qualified id. 

I prefer this approach as long as it's combined with appropriate 
feedback. Mentioning this in the release notes is important, but would 
it be possible to add a check when the build is executed? I'm thinking 
along the lines of, if no qualified ID is present in the apply() 
statement, then: 

1. warn that the user may have to update the ID 

We could do this.

The need to change will only occur when the user updates the plugin version, so the new qualified id will be on the classpath.

2. check whether the plugin repository contains a plugin of the same 
name, but with a qualified ID and let the user know that such is 
available. 

I don’t think this is worth it. As said above, this only comes about when users upgrade the plugin and the plugin changed to a qualified ID. So we can assume that in most cases the qualified ID is on the classpath and just do #1.




Peter 

-- 
Peter Ledbrook 
t: @pledbrook 

--------------------------------------------------------------------- 
To unsubscribe from this list, please visit: 

http://xircles.codehaus.org/manage_email 




— 

Luke Daley
Gradleware
Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com