Use newer PCT

[jglick]

Currently using an incremental deployment of jenkinsci/plugin-compat-tester#276. Need to get that released, and also check whether jenkinsci/plugin-compat-tester#299 reveals failures (supposedly something in `workflow-scm-step at least).

[jglick]

Another issue noticed in CB runs using aws-java-sdk is that either -Dset.changelist or -am -pl is needed when building a JEP-229-enabled plugin which uses a reactor. The current -f repo/submodule build does not work for modules which depend on siblings because the sibling snapshot is not present in the local reactor. So activate -am -pl whenever

mvn -Dexpression=project.version -q -DforceStdout help:evaluate | fgrep -- -SNAPSHOT

perhaps.

[jglick]

see jenkinsci/plugin-compat-tester#318

[basil]

This long-standing issue, caused by the introduction of an unmerged and unreleased upstream change in a non-draft PR in #213, is blocking fixes like jenkinsci/plugin-compat-tester#353 from being deployed to this repository and disincentivizing the development of fixes for other issues like #821 and #895. I am asking that we set a target date for the resolution of this issue.

[jglick]

Updated #659 to see what the current list of problems is, though I am more inclined to work on jenkinsci/maven-hpi-plugin#66 than to sink much more effort into PCT which in its current form seems fatally flawed.

blocking fixes like jenkinsci/plugin-compat-tester#353 from being deployed to this repository

Well, not “blocking” but making them more awkward since you need to merge them into the list of running patches first.

[basil]

I am more inclined to work on jenkinsci/maven-hpi-plugin#66 than to sink much more effort into PCT

But even even jenkinsci/maven-hpi-plugin#66 requires a patch to PCT, which in turn requires this issue to be resolved in order for such a patch to be deployed to this repository.

Well, not “blocking” but making them more awkward since you need to merge them into the list of running patches first.

And become the de facto maintainer of that list of running patches? No thanks.

[jglick]

even jenkinsci/maven-hpi-plugin#66 requires a patch to PCT

Most likely it would mean that we would still use PCT but in a much simplified form that just handled checking out repos and running a single mvn verify with an option pointing to a WAR or other source of dependency versions, but without any of the crazy POM rewriting.

Anyway, yes, we need to get trunk PCT working here somehow. Still TBD whether configuration-as-code/test-harness is the only outstanding problem.

[basil]

Still TBD whether configuration-as-code/test-harness is the only outstanding problem.

To be determined by whom?

[basil]

Updated #659 to see what the current list of problems is

While that helps clarify the nature of this long-standing issue, caused by the introduction of an unmerged and unreleased upstream change in a non-draft PR in #213, updating #659 to see the current list of problems still does not resolve this issue.

[basil]

Not sure why this was closed, but the issue remains present. This repository still uses an old PCT. Reopening.

[timja]

GitHub comment detection was a bit keen I think