Maintenance Strategy

[bdellegrazie]

Dear Community,

After several PRs raised and no change or review response from @jk1 it looks like we need a community fork, especially to deal with at a minimum operation on Gradle 9.

I am in the process of creating one and will release it in a couple of days - it will be public and Apache 2 licensed as is this one.

This in no way detracts from the great work @jk1 has done and if they wish to take ownership again we will happily help.

Likewise if there are other maintainers who wish to help maintaining this product we're more than happy to have others share the burden (once released!)

I'll link on this issue when this is complete but shouldn't take more than a day or two now.

Thanks

[bdellegrazie]

Tagging people with open PRs (in no specific order): @jparise, @chadlwilson, @patricklucas, @olgunkaya, @suniala, @AlexanderBartash, @Vampire, @balrok, @tonylee19544

[Vampire]

Great to hear, thanks.
Unfortunately, I have way too much on my plate already anyway, so will not be able to engage in active maintainership, more than sending PRs occasionally.
Feel free to merge my PR over to the new fork though, great to see someone stepping up to rescue the project as long as @jk1 does not have enough capacity to have some attention for this project.

Or maybe @jk1 would be open to add additional maintainers to this project, so that it can be evolved in-place without the need for a fork. 🤷‍♂️

[olgunkaya]

Thanks for this "stand up". I tried to reach to jk1 through different channels but that was no chance also. Let's focus on what's our next target. are you going to collect all PR's to the fork also or waiting an action from us ?

[chadlwilson]

Thanks for raising the topic @bdellegrazie

The PR I raised at #340 was really just a starting point to see if it would get any traction (which it didn't! ☺️), to conclude if it was perhaps worth looking into some of the other refactors/tidies necessary.

the great work @jk1 has done and if they wish to take ownership again we will happily help.

Curiously, jk1 has recently committed stuff relating to Gradle 9 on a sister plugin at https://github.com/jk1/TeamCity-dependencies-gradle-plugin however has not appeared responsive to GitHub Notifications generally speaking over recent times. This leaves the project in a bit of a messy state if there are no other committers.

it looks like we need a community fork, especially to deal with at a minimum operation on Gradle 9.

For what it's worth, warnings-aside even without my PR I do have things working fine on Gradle 9.1 with some manual inter-task dependency definition and forced early-configuration when running the license report so the current state is not totally fatal for me. Some extra build code sets every ReportTask's inputs via input.files(otherProject.relevantConfiguration) which gets things generally going.

[bdellegrazie]

@Vampire

maybe @jk1 would be open to additional maintainers.

100% agree - if that's the case this fork would not be necessary.

@olgunkaya

are you going to collect all PR's to the fork also or waiting an action from us ?

I have collected some of them, the simpler ones, and merged them already. I'll test locally and provided there are no issues publish a "3.0" release with a new ID likely in a day or two.

The repo will be made public prior to publication on Gradle Portal as is required.
At that point, any PRs outstanding can be rebased and re-raised, sorry in advance.

@chadlwilson
I'm testing locally with Gradle 9.1 now too. Hopefully the fixes already merged will be sufficient.

[jk1]

Hi all,

I'm terribly sorry that I wasn't able to answer timely, if at all, during past several months. It just so happened that I needed 100% focus on my main job.

I really appreciate the pull requests provided by the community and will happily promote @bdellegrazie as a fellow maintainer. With two of us looking after the codebase, things should get back on track real soon.

Thank you all for your patience and understanding.

[bdellegrazie]

@jk1 no need to apologise, we're just glad you're alive and well.

You may wish to add more than just me (or even someone else instead of me, if that's your preference), to ensure you have sufficient coverage / support.

I'll ask the question here because the majority of contributors are already on this issue - does anyone else wish to be a maintainer?

[bdellegrazie]

@jk1 any objection to adding release-please to the repo?

(I have a working config for that, to ease concern)

The one caveat is that we'd need to create an additional v2.9.0 tag corresponding to the v2.9 tag to avoid last release detection issues (it works with semver only), from then on it should work seamlessly.

Intent is to be able to generate release artifacts from Github Actions - minimising risks of manual build.

[jk1]

@bdellegrazie I have no prior experience with release-please in particular, but the overall idea sounds good to me.
Please go ahead and add it.

[bdellegrazie]

@jk1 done: #346
sorry for the spam everyone else, I'll figure out a way to communicate with @jk1 directly and we'll close this issue.
Once release-please is merged my plan is as follows:

1. Start with Gradle upgrade to 8.14.x (to fix compatibility with Gradle 9) - this will break compatibility with Gradle 6
2. begin merging the other simple PRs.
3. Do a release 3.0.0
4. ask the author(s) to rebase their more complicated PRs on top of master
5. release as needed.

I've made the assumption that Gradle 6 compatibility is not a huge requirement - if that's not the case, please raise a concern.

[Vampire]

this will break compatibility with Gradle 6

Don't raising concern, just mentioning it does not have to.
You can for example also release multiple variants of the plugin for different Gradle version and on usage, the right variant is automatically selected by Gradle, just in case you did not know. :-)

[bdellegrazie]

@Vampire thanks.
It's more which JDK is used to build the artefact. In this case Gradle 8.14.x requires minimum JDK 17, Gradle 6 has max of 16 so there's no overlap. Moving to Gradle 8.14 and JDK 17 supports Gradle 7, 8 and 9 which should be sufficient for most users (subjective opinion).

I personally don't want to maintain a higher level of complexity unless it's strictly necessary.

However, do you have an example link anywhere please? I promise to at least look at it.

[chadlwilson]

I see no reason to support Gradle 6 in 2025. They can always keep using old versions of the plugin.

[Vampire]

In this case Gradle 8.14.x requires minimum JDK 17

It does not.
Gradle 9 requires JDK 17 to run.
But that has nothing to do with what version you compile your code for.
Gradle 8.14.3 has still JDK 8 as minimum requirement.
So unless you want to drop support for everything below Gradle 9, I suggest you compile for release JDK 8 even if you use a newer JDK version to run Gradle, that's also exactly what JVM toolchains feature and JVM Deamon Criteria are for. :-)