Ensure tagged releases don't depend on ephemeral dependencies

[mfussenegger]

Currently tagged commits of eclipse.jdt.ls often depend on snapshot releases of the eclipse core/platform. The snapshot releases are wiped once a new eclipse core release is out, breaking all eclipse.jdt.ls commits which used these snapshots - often including tagged releases.

This is problematic for several reasons:

• For packaging for distributions it's often desired to use source builds.
• The unstable dependencies also affect projects like java-debug which afaik currently don't even have release artifacts other than the VSCode extension
• Currently it is pretty much impossible to use git bisect to find commits which introduced a regression.

Is there any chance to either:

• Copy the snapshots that are used as dependency to a location where they are preserved and use that
• Make sure tagged released don't use snapshots as dependency

?

[rgrunber]

I agree this is a problem for rebuilds, and it's something we've brought up in the past. The I-builds disappearing makes it especially difficult to track down possible regressions that came from upstream. The repo causing issues is mainly the Eclipse I-builds (eg .https://download.eclipse.org/eclipse/updates/4.31-I-builds/ ). JDT-LS releases about once per month, while Eclipse releases every 3 months (YYYY-03, YYYY-06, YYYY-09, YYYY-12). There's many instances where we consume changes that miss an Eclipse release, but make it early into the next release. Without being able to do this, certain improvements would take much longer to be released to users.

The only way to guarantee older builds can be reproduced is by copying the I-builds to a more permanent location. Maybe we could even generate a self-contained (uber) update site (would be smaller than the full I-build repo) that can be used in place of the original target file for building (triggered through pom profile?)