Considerations for gradle/community hub

[bric3]

I come from the shadowJar plugin, and I found a discussion about the future of the gradle plugin.

@oleg-nenashev (part of the gradle org) is gearing an initiative to "host" gradle plugins under a Gradle Community hub, which may have better integration with gradle documentation.

• Future home/support for Shadow? GradleUp/shadow#908 (comment)
• 🌐 Community Hub for Gradle plugins and integrations gradle/community#15

I know that gradle internals made things difficult for this beloved project, maybe there's a chance to improve the situation.

[ben-manes]

Thanks @bric3 and @oleg-nenashev, but unfortunately I don't see how this helps us? It sounds like it is the Apache model for providing infrastructure and a governance model, but leaves the development and support to the community. If the project is inactive then it is archived to the attic.

Since there is no promise or expectation for contributing to the hosted plugins, at best then does it encourage others to participate by moving it away from a personal repository? Sadly that might have the opposite effect of letting the original maintainer wash their name off of the project to remove a feeling of responsibility, resulting in the project finally dying. Until there is an active community showing interest in the adopted projects then I am afraid this appears to be a branding exercise?

I'm open to discussing the technical challenges and best path forward. I am excited for the idea but am confused if this is beneficial for dormant plugins like this one and shadow.

[oleg-nenashev]

It sounds like it is the Apache model for providing infrastructure and a governance mode

Pretty much that, yes. There is another goal actually to facilitate best practices, and to attract contributors by providing "community infrastructure" around projects. This is what Apache Foundation is missing

leaves the development and support to the community.

Yes, though it may imply some individual and company contributors stepping in and contributing. Normally it is easier for an organization

Sadly that might have the opposite effect of letting the original maintainer wash their name off of the project to remove a feeling of responsibility, resulting in the project finally dying

It might. At the same time, I strongly believe that the feeling of responsibility is a bad motivation on its own. I saw too many burnouts in the community, and I would rather prefer a maintainer to move on to other projects, ideally within the community, than to be stuck maintaining a particular component they do not longer want to.

For me offering maintainers a way to ensure sustainability of the project and being able to move on is an advantage for this organization.

Until there is an active community showing interest in the adopted projects then I am afraid this appears to be a branding exercise?

We're working on it (c)

[ben-manes]

That all sounds good. I think any migration requires a transition plan so the goals are known and achievable.

I believe the continuity of this plugin should really be the Gradle's team decision of how they want users to discover dependency updates. That has three phases: collect dependencies, discover updates, and report on them.

@bigdaz has been doing excellent work with the dependency-submission github action for Dependabot, which leverages the github-dependency-graph-gradle-plugin. While that is Github centric, it intentionally exposes enough for being used by other tooling through a parsable output format.

In this plugin the search for updates is performed by Gradle, thanks to @adammurdoch's suggestion on the old mailing list. This has become harder over time because of gradle module metadata and that some plugins (e.g. kotlin) add the necessary attributes by matching hard coded gradle configuration names in a strict lifecycle phase instead of by behavior, so resolving in new configurations at execution time may fail. We've of course had some pain for compatibility from Gradle 1.0 to today, but the folks have been wonderful. The big question is if Gradle believes that the build tool should offer this update search like Maven does or if they believe it should be handled by external tools (meaning not using Gradle's own resolvers).

If Gradle team decides that update checks should be supported by the build system, then reporting is the last minor hurdle. Mostly that is some settings in the prior step, e.g. skipping configurations or beta versions. How you present the work to humans and downstream tooling is fairly straightforward.

The clincher here is the discovery phase. If Gradle wants to make that first class then this plugin can go away as the reporting can trivially be handled directly. On the other hand, if Gradle prefers non-build tools like Dependabot handle it then likewise this plugin should be disfavored because it distracts everyone from the golden path. If there is a decision here then we can help guide users to make the transition smoother.