Does Play plugin need to be in Gradle core?

[nedtwigg]

I took a very shallow look at Gradle's support for Play, and it didn't jump out to me that the Play plugin needed to be part of the core. Looks like support for Play 2.6 was ready May 9, so we're coming up on a 3-month delay from "some usable code is available" to "that code can be used without a custom Gradle build".

Looks like 48 imports of org.gradle.internal.* in the source, and 7 more in the tests. Most of them looked like they could be worked-around.

I am crazy impressed by the velocity of the Gradle team, not knocking that at all. But I guess I'd expect the tooling around Play to move a little "faster and looser" than Gradle's core mechanisms, and I'm curious if the Play plugin will always be stuck at the same rate, or if it could be a separate plugin with a faster / looser release cycle.

FWIW, we're delaying Play adoption to see if it can be Gradle friendly, and the 3-month delay is, for now, signaling to us that structurally Play will always be hard on Gradle, and hard for us to help with. We can run custom Gradle plugins in-house, and easily contribute those improvements back upstream. Harder for us to run custom Gradle builds.

[big-guy]

Thanks @nedtwigg.

I think it's fair to say that Play has had a lower priority than a lot of the other things we've done lately, but we've always been slow about accepting PRs into Gradle core. We're trying to get better at it.

For Play, merging PRs have also required some domain knowledge about how Play-on-Gradle was implemented and where the warts/good parts were. There are only ~3 of us and we've been doing other things, unfortunately.

We've been talking seriously about separating Play support (everything in platformPlay) from Gradle core. There are a few things that needed to be done to make it acceptable for someone outside of the Gradle team to maintain it.

We've made progress on some of these things, but we're doing it in an opportunistic fashion:

• We need to limit/remove use of internal APIs
  • All of the compiler daemons are implemented using internal APIs, but they can now be replaced by the public Worker API in most cases.
  • I'm currently working on pushing the "deployment" API that PlayRun uses to be a public API
• We need to share our internal integration testing infrastructure or port the existing tests (and fixtures) into TestKit.
• Until Gradle 5.0, we need to repackage a particular version of the Play plugins into the Gradle distribution and/or decide it's worth breaking existing builds. We've been experimenting with this for the Kotlin DSL support.
• Automatically test the external Play plugins in our CI pipeline with nightly Gradle builds. We've setup some infrastructure to do this with important 3rd party plugins already.

Once the current Play 2.6-related PRs are merged, I'd like to take a "fast track" approach to any PR that only affects platformPlay, which will be close to "If it passes CI and has test coverage, I'll merge it." For larger changes, I'd still like to have some discussion before a big PR gets submitted.

[nedtwigg]

Thanks for the update! I think your priorities are reasonable, and your velocity is impressive. Glad to hear that there's a long-term eye on moving Play out of core. When that day comes, we'll be first in line to give it a try and send some PRs 👍

[bigdaz]

@nedtwigg Please don't wait for us to pull Play out of core before sending PRs! Within the Gradle team our knowledge and experience with Play is a bit limited, and we'd really appreciate the help.

@big-guy listed a bunch of stuff that needs to be done before we can truly split the Play support out of the core. But the code is already pretty self-contained, and we'd be happy for PRs to be submitted against the platform-play module. If we can get some key contributors to review the PRs (cc @benmccann), then we'll get them merged into master in a timely fashion.

[benmccann]

It looks like the project has now been moved out: https://github.com/gradle/playframework