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

Adopt the latest Gradle APIs #601

Closed
nedtwigg opened this issue Jun 5, 2020 · 6 comments
Closed

Adopt the latest Gradle APIs #601

nedtwigg opened this issue Jun 5, 2020 · 6 comments

Comments

@nedtwigg
Copy link
Member

nedtwigg commented Jun 5, 2020

There are three main tasks here:

Each TODO can be implemented independently, and should probably be in a separate PR (the bottom two could maybe be in one PR). As detailed in #600, this code is tested by :plugin-gradle:modernTest, and is not yet being used by end-users, though it is possible to opt-in with -PspotlessModern=true.

PRs welcome!

@bigdaz
Copy link
Contributor

bigdaz commented Jun 8, 2020

FYI I'm working on these.

@nedtwigg
Copy link
Member Author

nedtwigg commented Jun 9, 2020

From the migration guide for Gradle 6.5:

AbstractTask is an internal class which is visible on the public API, as a superclass of public type DefaultTask. AbstractTask will be removed in Gradle 7.0

Will its public methods become part of DefaultTask? We haven't upgraded the gradle wrapper to 6.5 in the spotless build yet (feel free to do so if you'd like in any modernization PR), but in other projects I'm getting deprecation warnings around calls to getProject() and getInputs(), which I guess will need to get injected into the constructor now?

@big-guy
Copy link

big-guy commented Jun 9, 2020

@nedtwigg do you have particular APIs in mind? I think everything that needs to be public is a part of the Task interface. Part of the reason to remove AbstractTask is to reduce places where internal interfaces leak into the public API (e.g., AbstractTask overrides getInputs to specialize the return type with an internal type).

Do you have any examples of deprecations to getProject or getInputs? Is that in the IDE?

Eventually something like tasks won't have direct access to the Project, but that's going to be awhile and the current way will keep working for some time.

@nedtwigg
Copy link
Member Author

nedtwigg commented Jun 9, 2020

Aha, I pretty much only care about getProject() and getInputs(), which are both in Task. Yeah, the deprecations I'm seeing are in Eclipse, e.g.

Screen Shot 2020-06-09 at 12 56 59 PM

I can resolve the warnings with ((Task) this), but I'll probably just leave them be.

@nedtwigg
Copy link
Member Author

The three todo's that we outlined in the top of this issue are now all complete. The only remaining items I can see are:

  • switching to Provider<> in the FormatExtension (discussed here)
  • using Worker to make within-project execution parallel
    • requires us to bump minimum from 5.4 to 5.6, not a big deal, and the worker api is still incubating
    • I think we're pretty darn thread safe already, so the Worker transition should be relatively painless if anybody wants to make it

If anyone wants to explore the Provider approach, I'm happy to allow time for that. Otherwise, I think we can safely say that -PspotlessModern=true is getting all the performance advantages that are allowed by the very latest version of Gradle, and close out this issue.

@nedtwigg
Copy link
Member Author

All of the above has been released in 4.4.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants