[Build] Use last successful ECJ snapshot in verification builds

[HannesWell]

Use the latest ECJ snapshot version from the last successful I-build (without comparator errors) for verification builds, to automatically align with I-builds.
Currently ECJ has to be deployed manually to a JDT snapshot-repository after changes in ECJ that caused comparator-errors:

• Comparator errors in I20241106-1800 eclipse-pde/eclipse.pde#1461 (comment)

This prevents issues like

• Class file diff in validation builds #1960
• Force qualifier update in org.eclipse.pde.api.tools eclipse-pde/eclipse.pde#1467

If there are no other usages of https://repo.eclipse.org/content/repositories/eclipse-staging, this should make the JDT Jenkins job to deploy ECJ to it obsolete

• https://ci.eclipse.org/jdt/job/copyAndDeployJDTCompiler/

as well as the target repository and should allow us to delete:
https://repo.eclipse.org/content/repositories/eclipse-staging

@jarthana and @akurtakov this is what we talked about in today's PMC call.
@MohananRahul can you please check if the release process documentation update is correct and fine?

[MohananRahul]

@MohananRahul can you please check if the release process documentation update is correct and fine?

Ok , looks good.

[akurtakov]

Looks good to me but let's land it after 4.34 is branched to prevent possible last minute surprise.

[HannesWell]

Looks good to me but let's land it after 4.34 is branched to prevent possible last minute surprise.

Acknowledge.

I have now changed this PR to use a version range for cbi-ecj-version:
<cbi-ecj-version>[3.40.0,4)</cbi-ecj-version>

This way the version does not have to be updated at all as long as ECJ stays at version 4.x. I tried this out in eclipse-pde/eclipse.pde#1467 and it worked as expected.
If we use this, we can simplify the release procedure and just drop the update step.
WDYT?

[laeubi]

Maven version ranges can give surprising results, e.g. a version of 4.0.0-alpha1 is included in your range.
It is also bad in terms of reproducibility as older branches will get suddenly newer releases.

[HannesWell]

Maven version ranges can give surprising results, e.g. a version of 4.0.0-alpha1 is included in your range.

In general for the master branch I assume that we want the latest version anyways, so the upper bound could be empty/infinity.

It is also bad in terms of reproducibility as older branches will get suddenly newer releases.

OK, for older branches this is indeed probably not wanted. I reverted that part.
Overall this is still a significant simplification.

If there are no other usages of https://repo.eclipse.org/content/repositories/eclipse-staging, this should make the JDT Jenkins job to deploy ECJ to it obsolete

* https://ci.eclipse.org/jdt/job/copyAndDeployJDTCompiler/

as well as the target repository and should allow us to delete: https://repo.eclipse.org/content/repositories/eclipse-staging

@jarthana or @akurtakov can you tell if there are other users of that repository? If not I suggest we delete that repository and see if there are any unknown users. And if nobody complains or someone cannot be moved to the maven-repo into that the I-builds deploy, we can continue to delete the Jenkins job too.

[akurtakov]

In the light of #2595 what prevents this one from merging? I'm not troubled by 4.0.0-alpha at all. There is no way to know whether this staging repo is used by anyone else but being "staging" means I have no concerns about changes in it.