Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Submit Gradle Plugin to Gradle Plugin Portal #895

Closed
axelfontaine opened this issue Dec 2, 2014 · 6 comments
Closed

Submit Gradle Plugin to Gradle Plugin Portal #895

axelfontaine opened this issue Dec 2, 2014 · 6 comments

Comments

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Dec 2, 2014

Before Gradle can include our plugin, we need you to fix two things:

  1. the 'gradle-plugin' attribute must be set on version level in bintray
  2. plugin id should be qualified (Breaking change)

more details at http://plugins.gradle.org/submit

@davidmc24
Copy link
Contributor

@davidmc24 davidmc24 commented Feb 2, 2015

It's possible for a plugin to have multiple ids, which would allow this to not be a breaking change. I've got an example of one technique to do that here:

https://github.com/commercehub-oss/gradle-avro-plugin

The basic idea is to maintain the existing flyway-gradle-plugin/src/main/resources/META-INF/gradle-plugins/flyway.properties file that allows use with the existing unqualified plugin id, and add an additional properties file for the new qualified plugin id.

In my example, I went one step beyond that, wrapping the plugin class to log a deprecation warning when the unqualified plugin id is used.

https://github.com/commercehub-oss/gradle-avro-plugin/blob/master/src/main/java/com/commercehub/gradle/plugin/avro/UnqualifiedAvroPlugin.java

@axelfontaine
Copy link
Contributor Author

@axelfontaine axelfontaine commented Feb 3, 2015

That's great news! That would allow for a smooth transition starting with 3.2. We could deprecate the old Id and remove it in 4.0. Is there a way for a plugin to know under which id it was used?

Would like to provide a PR?

Thanks
Axel

@davidmc24
Copy link
Contributor

@davidmc24 davidmc24 commented Feb 3, 2015

The way I managed awareness of the ID was to register a different class for each ID. I'll start work on a pull request.

davidmc24 added a commit to davidmc24/flyway that referenced this issue Feb 4, 2015
axelfontaine added a commit that referenced this issue Feb 25, 2015
#895: Add qualified Gradle plugin ID, deprecate unqualified Gradle plugin ID
@davidmc24
Copy link
Contributor

@davidmc24 davidmc24 commented Feb 25, 2015

Now that #946 is merged, it should be possible to submit the gradle plugin to the plugin portal after the 3.2 release.

@axelfontaine
Copy link
Contributor Author

@axelfontaine axelfontaine commented Feb 25, 2015

Yes, that's the plan. Thank you again for the PR :-)

@axelfontaine axelfontaine added this to the Flyway 3.2 milestone Feb 25, 2015
@axelfontaine axelfontaine removed this from the Flyway 4.0 milestone Feb 25, 2015
@axelfontaine
Copy link
Contributor Author

@axelfontaine axelfontaine commented Mar 17, 2015

jmahonin pushed a commit to jmahonin/flyway that referenced this issue Jul 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants