Dependency Updates

[github-actions]

Please review the changes and merge if appropriate.

[mickaelistria]

Platform cannot handle most of suggested upgrades, as most would require some changes in the code. It would be more actionable if updates could be splitted in different PRs (eg slf4j can probably be updated without updating the other bits).
Some of the proposals seem plain wrong.

Overall, this PR is not actionable in the current state and it seems unlikely that it gets better very soon. So I'm going to remove the workflow that has created it.
cc @laeubi (and @merks and @akurtakov )

[mickaelistria]

This seems wrong.

[merks]

Yes, Maven Central is a bit of a dumping ground where no mistake is ever really gone. The Orbit generators have been carefully tailored to avoid such things, and sometimes special rules (pattern arguments to the generator) are needed to exclude things.

[mickaelistria]

We do want to keep the older version (together with newer) here.

[merks]

I'm pretty sure this will break dependencies. And I don't think a .MR version even makes sense:

[mickaelistria]

What's MR here?

[merks]

I think the ordering is maybe not implemented correctly?

[laeubi]

I have checked this one (also will double check with maven devs) but think it is actually correct as MR is only a random qualifier for maven and qualifier > no qualifier (like in OSGi). To make it a real MilestoneRelease it has to be M directly followed by a number (e.g. M1).

What came into my mind would be to have an ignore list of "bad" versions, but semantically this seems correct.

[merks]

Indeed, the Orbit generator has a bunch of rules about bad qualifiers as opposed to expected qualifiers.

It's rather adhoc.

Recently I had to add support for including M/RC in the updates, but those are updated if and only if the current version is a M/RC version so that once one is using a released version one is not switched to a M version even if it is greater.

The ordering rules are quite complicated so I keep a test program around where I can test the actual maven implementation's behavior. E.g.,

		System.out.println("###" + new TreeSet<ArtifactVersion>(Arrays.asList(new ArtifactVersion[] { //
				new DefaultArtifactVersion("2.0.1"), //
				new DefaultArtifactVersion("2.0.1.M1"), //
				new DefaultArtifactVersion("2.0.1-M1"), //
				new DefaultArtifactVersion("2.0.1-SNAPSHOT"), //
				new DefaultArtifactVersion("2.0.1.MR"), //
				new DefaultArtifactVersion("2.0.1-MR"), //
				new DefaultArtifactVersion("2.0.1-alpha"), //
				new DefaultArtifactVersion("2.0.1-beta"), //
				new DefaultArtifactVersion("2.0.1-RC11") //
		})));

It prints out the following, so quite a few rules for qualifiers with special meaning and well as the fact that that - versus . for the qualifier separator is considered equal for compareTo if not actually for .equals:

###[2.0.1-alpha, 2.0.1-beta, 2.0.1.M1, 2.0.1-RC11, 2.0.1-SNAPSHOT, 2.0.1, 2.0.1.MR]

[laeubi]

so that once one is using a released version one is not switched to a M version even if it is greater.

M Versions are not greater than releases, but using MR is simply wrong as this is not a special qualifier for maven (while M1, M2, ... R1, R2, ... and alike) are.

The rule is that you either has to write it out (long form e.g. -alpha) or single char followed by a number.

And _, . and - are considered equal.

[merks]

Note that the Orbit generator does mostly the same thing with this report indicating what new minor and major versions are available:

https://github.com/eclipse-orbit/orbit-simrel/blob/main/report/maven-osgi/platform/REPORT.md#target-platform-platform

The generator also produces an update target, but it only updates to minor new versions not major new version:

https://github.com/eclipse-orbit/orbit-simrel/blob/main/report/maven-osgi/platform/updated.target

For me locally, the orbit generators and analyzers save this updated.target directly into the git clone of the aggregator where I can create a PR in the SDK IDE.

I generally do the Orbit build first, to ensure that all the license views have passed and to ensure that all dependencies are available before I create a PR.

Yesterday, for example the slf4j update was broken:

qos-ch/slf4j#421

so I did not create a PR for that broken version.

The Orbit generator is also careful about what types of suffixes is will use for the updates.

This is all to say that a different way of accomplishing this same goal doesn't save me personally a significant amount of time. What would make me happy is if the auto-merge-when-build-succeeds worked, but it doesn't and I don't know why.

[laeubi]

Overall, this PR is not actionable in the current state and it seems unlikely that it gets better very soon. So I'm going to remove the workflow that has created it.

As mentioned in the original PR I'm a bit sad about this back-and forth without having the chance to react to the concerns. This PR does not harm anything and actually it is not the workflow to blame here but one needs to enhance (or fix) the tycho-version-bump:update-target mojo.

Note that the Orbit generator does mostly the same thing with this report indicating what new minor and major versions are available

For orbit? Or for Platform? or for any projects (e.g m2e ?)

The generator also produces an update target, but it only updates to minor new versions not major new version

That's probably the first thing that needs to be enhanced.

This is all to say that a different way of accomplishing this same goal doesn't save me personally a significant amount of time.

For me this is more an attempt to get something working for projects that is independent of an individual person, easy to use and setup and providing some basic automation. If the orbit workflow even "works" it requires a lot of manual work and still requires that downstream projects perform additional (manual) work.

What would make me happy is if the auto-merge-when-build-succeeds worked, but it doesn't and I don't know why.

Is there an issue describing what is "not working", I set this up for Tycho a while back and didn't see much of an issue.

[merks]

I think many people would find what Tycho is trying to do here very useful. What Orbit does has a different focus, though with overlapping capabilities, but that's not a reason Tycho shouldn't provide such capabilities directly.

I was surprised the test workflow was merged without consulting with you and then unmerged also without consulting with you. To me it seems interesting and useful to fine tune the behavior in a more complex environment like the Platform.

[laeubi]

I tried working on a switch to not update major versions here now:

• Do not update to the next major version unless explicitly requested eclipse-tycho/tycho#4097