Support for Java 11

[rkrisztian]

Currently the GoCD main code is written with Java 11 compatibility:
https://github.com/gocd/gocd/blob/master/build.gradle#L151
Compared to that, GoCD plugins are configured to only use Java 8 features. I wish to use Java 9 features like Map.of, but I cannot, because of this rather outdated restriction. Could you please update this limitation?

Disclaimer: yes, probably we can derive the conclusion for ourselves that these Gradle files are just helpers and we can override the target compatibility in our plugin, but the helper defines what we are inclined to assume as "this is how it works, they probably know it better, and we should just trust it, rather than potentially breaking stuff", and it takes time to understand the real situation. By the time I collected this information, I already went ahead and coded without Map.of, as well as opened this ticket.

Edit: If Java 8 has to be kept for compatibility reasons in this repository, at least we should document somehow that we are allowed to go up to Java 11...

[chadlwilson]

Sorry, where is it that you think refers to Java 8 in this repository? I don't know the specific reason why but the helpers only apply restrictions to subprojects (seemingly not the root/parent project so wouldn't affect many plugins) and where it does, it is Java 11.

gocd-plugin-gradle-task-helpers/helper.gradle

Lines 35 to 40 in db99246

	subprojects {
	apply plugin: 'java'
	sourceCompatibility = 11
	targetCompatibility = 11
	}

Not sure which plugin you are referring to, but perhaps it is referring to an outdated fixed SHA for the helpers?

Perhaps you are referring to https://github.com/adnovum/tenantsecrets/blob/4e02e9d1874a3e3e7b74f9c6862026bcc0b438ce/build.gradle#L5 which does indeed refer to a fixed SHA from 2020, rather than latest - so you're getting the behaviour you asked for?

[rkrisztian]

Oh, I see, I think I've been using an old version:
https://raw.githubusercontent.com/gocd/gocd-plugin-gradle-task-helpers/75a8575/helper.gradle
Sorry about this. Looks like an invalid ticket then.

[chadlwilson]

No problem. I must admit this approach of applying helpers like this seems to be a bit odd to me, and not personally entirely sure it's within the Gradle spirit, compared to other approaches, but seems to work generally OK for now apart from the challenges of either depending on mutable config from some other repo (which many would consider bad practice due to mutability and risk) or using a fixed commit sha which is hard to detect needs update, no help from dependabot etc.

[rkrisztian]

Typically the approach to providing common setup for Gradle projects is the use of Gradle plugins. The Plugins DSL also provides some extra benefits to reused code like optimizing their load, providing IDE assistance. Indeed because a Gradle plugin is a real dependency, Dependabot can also help out there with the tracking of new versions. At the same time the helper approach also works for us at least, so I'm not complaining at all. Plugin projects are relatively small, so even if I considered using the Task Configuration Avoidance API but couldn't make full use of it due to the helper code written in the old way, I don't lose much really, at least not yet.

At the same time, I am kind of considering offering help for a rewrite into a plugin, even if it has to be in my unpaid time.

[chadlwilson]

I'd possibly be interested in collaborating on that. All of the 'official' GoCD and gocd-contrib plugins use this helper approach right now (usually depending on latest code) and I have similar challenges. Currently I don't think these helpers will work on Gradle 8 (although haven't tried) and I'd like to move all the dependent plugins to Gradle 8 so some work may be needed regardless of whether we keep the helpers.

[rkrisztian]

OK, I can create a PR next week for a plugin rewrite that would support Gradle 8, if you want.

[rkrisztian]

@chadlwilson , I've started working on the PR. It looks like this currently:
master...rkrisztian:gocd-plugin-gradle-task-helpers:master
Let me know if you like it so far. In the end I would of course create a proper pull request.
Edit: Later of course we can configure a GitHub Action for it to run the tests.

[rkrisztian]

@chadlwilson , here's the pull request:
#16
I guess we can continue the discussion there?

Since you said that you would possibly co-operate in the making of this plugin, feel free to continue my work, in fact it would help me a lot because I already spent more than I thought I would. :)