[JENKINS-58028] Add GMavenPlus version

[bitwiseman]

Eventually will replace gmaven with gmavenplus.

This commit should not change downstream behavior aside from setting the version of GMavenPlus.

[oleg-nenashev]

Please provide a downstream PR with an update which uses GMavenPlus

[bitwiseman]

@oleg-nenashev
See jenkinsci/plugin-pom#209 and related for examples.
However, there's no downstream changes needed for this change. This only enables use of gmavenplus with a consistent version. I'm not even sure what projects are directly downstream from this pom. Suggestions?

[oleg-nenashev]

Right, I did not notice that the execution section was for lifecycleMappingMetadata

[oleg-nenashev]

Any plans to finish it @bitwiseman ?

[oleg-nenashev]

+1 for getting it over the line. Taking the experience with GMavenPlus in other components, I think it is ready to go

[bitwiseman]

@oleg-nenashev I've been heads down on Matrix. I'll get back to it when that clears.

[oleg-nenashev]

Should we go ahead and replace GMaven @jenkinsci/core ? AFAICT it is no longer maintained, and the same patch has worked quite well for plugins

[jglick]

Merge conflicts here.

This is OK though I would still generally recommend components not use Groovy sources to begin with. pipeline-model-definition is the main offender (among Maven-based repos at least).

[basil]

Do we need this in the parent POM? I looked around for usages of GMaven in any POMs whose parent is this repository and the only two I could find were acceptance-test-harness and lib-groovy-guice-binder (itself only consumed by acceptance-test-harness). If this is only used by acceptance-test-harness then perhaps we should close this PR and just migrate acceptance-test-harness and lib-groovy-guice-binder to GMavenPlus directly?

[bitwiseman]

@basil
Having this version controlled in the POM would be better.

As Oleg noted GMaven is no longer maintained and this replaces that. If anyone uses GMaven, this makes it easy for them to switch and standardized the version of GMavenPlus that gets used.

[basil]

Having this version controlled in the POM would be better.

I trust that you've looked into this, but I don't quite see the reason why it would be better. From a different perspective, it could be argued that slimming down the dependency tree of the POM would be better. Either way, I have no strong preference, but I do have a preference that we file downstream PRs in acceptance-test-harness and lib-groovy-guice-binder adapting them to the changes in this PR.

[jglick]

-0 I suppose. Harmless, though most components should not be using Groovy sources, and for those that do, I see no particular advantage in managing the mojo version here.

[bitwiseman]

-0 I suppose. Harmless, though most components should not be using Groovy sources, and for those that do, I see no particular advantage in managing the mojo version here.

For the projects that do, it is better that we guide them away from GMaven to GMavenPlus and to not managing the version of the plugin on their own.

[jglick]

guide them away from GMaven to GMavenPlus

Sure.

to not managing the version of the plugin on their own

Why? Usually we add a Maven plugin version to a POM either because it is widely used, or because we define some configuration for it, or because unexpected updates could have bad interactions with something else we define. Miscellaneous plugins used by particular components for idiosyncratic reasons (Shade, for example) do not particularly benefit from being defined in some parent. It just makes for one extra level of indirection in Dependabot.

[jglick]

As of jenkinsci/acceptance-test-harness#719 we are down to lib-groovy-guice-binder, an odd little library which seems to be a dependency of acceptance-test-harness.

[timja]

Apparently used for https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/WIRING.md#configuring-how-to-run-tests

@jtnord / @olivergondza are either of you using this functionality?

[jglick]

Yes various ATH scripts define CONFIG as per this implementation; example.

[basil]

There has been no interest in this during the intervening year.

[jglick]

In fact we have been moving to remove src/{main,test}/groovy/ in various repos.