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

Ensure plugin cross-version compatibility by allowing a user to depend on gradlePublicApi() #1156

Open
eriwen opened this issue Jan 12, 2017 · 14 comments

Comments

@eriwen
Copy link
Member

commented Jan 12, 2017

Provide a way for users to declare that they only depend on the Gradle Public API.

Expected Behavior

Allow a user to declare a dependency on only the gradlePublicApi().

Current Behavior

Currently, users wanting to write plugins must declare a compile gradleApi() dependency which exposes all of Gradle's internals and pulls in a bunch of transitive dependencies.

Context

Plugin authors are not prevented from using Gradle internal APIs (which are sadly necessary for some users' needs today) which breaks backward and forward compatibility.

Users have complained about this situation again, and again, and again.

Let us give them a vehicle to ensure compatibility, then make that vehicle awesome.

More discussion at gradle/build-tool-projects#73

Edit See the initial specification by @bmuschko

@eriwen eriwen added the a:feature label Jan 12, 2017

@eriwen eriwen changed the title Create a public-api-only core dependency Ensure plugin cross-version compatibility by allowing a user to depend on gradlePublicApi() Jan 12, 2017

@adammurdoch

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

We should bust up the API into the public API for the Gradle platform, and the public API of each group of plugins. For example:

dependencies {
    compile gradlePublicApi() // only the API of the Gradle platform, no plugins
    compile plugin id 'java'  // the API of the java plugin
    compile plugin id 'my.org.plugin' version '1.2' // the API of my custom plugin
}

@bmuschko bmuschko self-assigned this Mar 2, 2017

@eriwen eriwen added this to the 4.0 RC1 milestone Mar 2, 2017

@lacasseio

This comment has been minimized.

Copy link
Member

commented Mar 15, 2017

Issues like #1021 may need to be resolved in order to give good user experience.

@bmuschko

This comment has been minimized.

Copy link
Contributor

commented Mar 15, 2017

@lacasseio I don't think it should necessarily hold us back from implementing this issue but to be able to fully avoid the use of internal APIs #1021 would have to be fixed. Some people might not be affected e.g. if you implement your logic in Groovy and don't use strong typing.

@lacasseio

This comment has been minimized.

Copy link
Member

commented Mar 15, 2017

@bmuschko You are right. It's something to keep on the radar.

@adammurdoch

This comment has been minimized.

Copy link
Member

commented Mar 16, 2017

Just repeating a previous comment: We should bust up the API into the public API for the Gradle platform, and the public API of each group of plugins.

@bmuschko

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2017

@adammurdoch Can you have a look at the spec I wrote as a first step of approaching the problem? I'd like to defer implementing a public API for the plugins in a later story.

@bmuschko bmuschko added the epic label Mar 17, 2017

@bmuschko bmuschko removed their assignment Mar 24, 2017

@bmuschko bmuschko removed this from the 4.0 RC1 milestone Mar 30, 2017

@JLLeitschuh

This comment has been minimized.

Copy link
Member

commented Oct 3, 2018

@bmuschko The link to the spec you wrote is broken.

@bmuschko

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2018

@JLLeitschuh AFAIR the design-docs folder has been deleted from the repository. I am not quite sure if there is a replacement for it.

@JLLeitschuh

This comment has been minimized.

Copy link
Member

commented Oct 3, 2018

@bmuschko Do you want to post the proposal you had somewhere where it can still be read?

@bmuschko

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2018

@JLLeitschuh I don't have it anymore on my local machine. I am sure you can find it in the Git history though for an older tag.

@TWiStErRob

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2018

Are you planning to do this for 5?

@lptr

This comment has been minimized.

Copy link
Member

commented Nov 5, 2018

Not for 5 yet, unfortunately.

gradlewaregitbot pushed a commit that referenced this issue Feb 7, 2019

Merge pull request #1156 from gradle/bamboo/plugin-id-accessors
ntroduce type-safe accessors for plugin ids
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.