Update the dependencies to newer minor versions

[merks]

Fixes #1145

[github-actions]

Test Results

610 tests  ±0   603 ✔️ ±0   10m 34s ⏱️ +25s
  98 suites ±0       7 💤 ±0 
  98 files   ±0       0 ❌ ±0 

Results for commit 965797e. ± Comparison against base commit 2a76924.

♻️ This comment has been updated with latest results.

[merks]

I can't tell if the failure is related to the changes. Maybe some version needed to be incremented?

[laeubi]

The feature needs a version increment:

[INFO] --- tycho-baseline-plugin:4.0.0-SNAPSHOT:verify (baseline-check) @ org.eclipse.m2e.feature ---
11:08:51  [ERROR] ┌──────────────────────┬──────────────────────┬──────────────────────┬──────────────────────┬──────────────────────┬─────────────────────┬─────────────────────┐
11:08:51  [ERROR] │Change                │Delta                 │Type                  │Name                  │Project Version       │Baseline Version     │Suggested Version    │
11:08:51  [ERROR] ├──────────────────────┼──────────────────────┼──────────────────────┼──────────────────────┼──────────────────────┼─────────────────────┼─────────────────────┤
11:08:51  [ERROR] │MINOR                 │CHANGED               │FEATURE               │[feature] M2E -  Maven│2.1.3.20221216-0937   │2.1.2.20221130-2239  │2.2.0                │
11:08:51  [ERROR] │                      │                      │                      │Integration        for│                      │                     │                     │
11:08:51  [ERROR] │                      │                      │                      │Eclipse               │                      │                     │                     │
11:08:51  [ERROR] ├──────────────────────┼──────────────────────┼──────────────────────┼──────────────────────┴──────────────────────┴─────────────────────┴─────────────────────┤
11:08:51  [ERROR] │MINOR                 │CHANGED               │REQUIREMENT           │Requirement org.eclipse.equinox.p2.iu:org.eclipse.m2e.workspace.cli changed version from │
11:08:51  [ERROR] │                      │                      │                      │0.3.1 > 0.4.0                                                                            │
11:08:51  [ERROR] └──────────────────────┴──────────────────────┴──────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────┘

[merks]

Yes, that make sense. I was just using the github edit file functionality on a web page to create this patch, but I don't think I can use that to add another edited file to this PR. At least I don't know how to do that so maybe there is a way I don't know about...

[laeubi]

Yes, that make sense. I was just using the github edit file functionality on a web page to create this patch, but I don't think I can use that to add another edited file to this PR. At least I don't know how to do that so maybe there is a way I don't know about...

It is not very obvious, but it works the following way:

1. Open your branch https://github.com/merks/m2e-core/tree/patch-2
2. Navigate to the file you like to adjust
3. edit it and then chose "commit directly to patch-2 branch"

[merks]

I see! That's cool!! Should I go with the suggest version 2.2.0?

[laeubi]

I see! That's cool!! Should I go with the suggest version 2.2.0?

Yes, we currently try out the new enforced rules at m2e and I don't see anything wrong here wit 2.2.0

[merks]

I went with 2.2.0. Given it's so easy to change, it can be adjusted if that's not the version we want...

[HannesWell]

I see! That's cool!! Should I go with the suggest version 2.2.0?

That's fine. Die Overall M2E 'branding' Version is at 2.2 anyways.

Regarding the Update of takari-workspace cli: IIRC this requires Code changes. Therefore expect this simple Update to fail.

[merks]

@HannesWell

Yes, I wondered about that version being "ignored" because it's also a very old version and is only a few days newer than the previous version:

https://repo1.maven.org/maven2/io/takari/m2e/workspace/org.eclipse.m2e.workspace.cli/

So it seemed kind of deliberate to use a back-level version...

[merks]

@HannesWell This is probably the failure you were expecting. I'll be out of office until Tuesday and need to leave now...

[HannesWell]

Thank you Ed!
Btw. will the report you did be automated so that we can have some sort of dependabot for Maven-target?
Of course it would be ideal to make dependabot process (Maven-)Targets as well, but as far as I know nowbody from the Eclipse community knows Ruby. :/

[merks]

Yes, I'm automating everything...

The analyzer depends only on what's available in the JRE. It produces a report for each *.target that it processes (while building a composed *.target), recording the *.target as it exists in git as well as the version after applying updates. It only applies minor version updates.

Here is how it looks in my workspace, comparing the before and after versions of the m2e *.target:

The report can be pasted into any github issue or PR like this:

Target Platform: target-platform.target

Minor Updates

• ch.qos.logback
  • logback-classic 1.2.11 < 1.4.5
• io.takari.m2e.workspace
  • org.eclipse.m2e.workspace.cli 0.3.1 < 0.4.0

Major Updates

• org.slf4j
  • slf4j-api 1.7.36 < 2.0.6

Updates Applied

updated.target

Content

• biz.aQute.bnd
  • biz.aQute.bnd.util 6.4.0
  • biz.aQute.bndlib 6.4.0
• ch.qos.logback
  • logback-classic 1.2.11
• com.google.code.gson
  • gson 2.10
• com.google.guava
  • failureaccess 1.0.1
  • guava 31.1-jre
• io.takari.m2e.workspace
  • org.eclipse.m2e.workspace.cli 0.3.1
• org.osgi
  • org.osgi.service.repository 1.1.0
• org.slf4j
  • slf4j-api 1.7.36

Probably each project will want its own job to run such a thing so I'm trying to keep things flexible and reusable...

And yes, I have no clue about Ruby for deeper dependabot integration....

[HannesWell]

Sounds interesting. Thank you for your elaboration.
Having that as GH workflow that maybe runs once a day or week (or what ever configurable? period) would be nice. That job could then even create an issue about outdated deps, but then you also need the functionality to silence it or not to repeatably creating issues about the same dependency. So in the end we would write our own dependabot 🙉 So maybe such job should only be triggered manually?

[HannesWell]

I also noticed from this change that I now have resolution errors in my TP because eclipse.lsp4j requires gson 2.9.1:

I'm surprised the build passed with that and I wonder why lsp4j has such tight version ranges.
@jonahgraham the history of https://github.com/eclipse/lsp4j says you are quite active there. Can you please explain that?

[jonahgraham]

Short answer is that com.google.gson wasn't doing strict semantic versioning so we locked down the versions to what we were testing. Some more details of when we restricted the range are found in this comment thread.

I am more than happy to open up the range/change lower bound to 2.10.0. A newer version is needed in Orbit and/or the LSP4J gradle build needs to be updated some other way to consume direct from Maven.

The version restriction is coded here: https://github.com/eclipse/lsp4j/blob/b17a5f1c6f2f0a05901fcfc47f11f98d2b303f5f/gradle/versions.gradle#L19

[jonahgraham]

PS and FWIW the gson 2.10.0 looks like a safe change API wise compared to 2.9.1. I attached the japicmp report (zipped up)

[HannesWell]

Short answer is that com.google.gson wasn't doing strict semantic versioning so we locked down the versions to what we were testing. Some more details of when we restricted the range are found in this comment thread.

Yes that's an annoying thing with Guava and Gson. :/
Do you use BND to generate the version ranges?

I am more than happy to open up the range/change lower bound to 2.10.0. A newer version is needed in Orbit and/or the LSP4J gradle build needs to be updated some other way to consume direct from Maven.

Great, I just created eclipse-lsp4j/lsp4j#690 to widen the range. I hope that is sufficient for you. Since I'm not familiar with Gradle and have also many other open tasks I would prefer to leave the task of updating deps to you or others from the lsp4j team.

[HannesWell]

Until that is available I will revert this PR to be able to launch M2E from my dev workspace.
Sorry Ed.

[merks]

I remember asking way back when, "Without Orbit how will we coordinate using single common version?" and the answer was "In my experience, the only way to make that work is everyone uses the latest version?" But that seems kind of an impossible task too. 😞

It's a rapidly moving target where this is m2e's state (where I don't really see a revert):

Minor Updates

• ch.qos.logback
  • logback-classic 1.2.11 < 1.4.5
• com.google.code.gson
  • gson 2.10 < 2.10.1
• io.takari.m2e.workspace
  • org.eclipse.m2e.workspace.cli 0.3.1 < 0.4.0

The platform is also falling behind:

Minor Updates

• com.google.code.gson
  • gson 2.10 < 2.10.1
• net.bytebuddy
  • byte-buddy 1.12.20 < 1.12.21
  • byte-buddy-agent 1.12.20 < 1.12.21
• org.assertj
  • assertj-core 3.23.1 < 3.24.1
• org.mockito
  • mockito-core 4.10.0 < 4.11.0
• org.osgi
  • org.osgi.service.component 1.5.0 < 1.5.1
  • org.osgi.service.component.annotations 1.5.0 < 1.5.1
  • org.osgi.util.promise 1.2.0 < 1.3.0
  • org.osgi.util.pushstream 1.0.2 < 1.1.0

[HannesWell]

I remember asking way back when, "Without Orbit how will we coordinate using single common version?" and the answer was "In my experience, the only way to make that work is everyone uses the latest version?" But that seems kind of an impossible task too. 😞

The first two are unfortunately dependencies were we depend on others, be it lsp4j or slf4j. :/
I'm hoping for some progress at least in slf4j soon.
The good thing is that m2e only consumes those deps in the build and does not (re) publish them. So once lsp4j is ready for the latest gson, the SImRel can update even that m2e only uses released builds.

The io.takari.m2e.workspace is indeed something we could change, but since nothing is happening in that library and that update is not critical, nobody stepped up yet to do do the necessary adjustments in m2e.

[jonahgraham]

Thanks @HannesWell for the PR on LSP4J, I have approved the variant for merging.

As for coordinating versions that also requires LSP4J release everytime a new version of a dependency comes in. I am pretty happy to release LSP4J quite often. Follow along with eclipse-lsp4j/lsp4j#685 and add your input there on when you want an LSP4J release.

[HannesWell]

Thanks @HannesWell for the PR on LSP4J, I have approved the variant for merging.

As for coordinating versions that also requires LSP4J release everytime a new version of a dependency comes in. I am pretty happy to release LSP4J quite often. Follow along with eclipse/lsp4j#685 and add your input there on when you want an LSP4J release.

Thanks for that offer. After investigating that a bit deeper (due to #1197 (comment)) I noticed that a matching version is actually present in the TP. Therefore I assume that PDE somehow fails to resolve that properly, but I'll investigate that in PDE.