Add a negative requirement to exclude bad o.a.commons.logging version

[merks]

No description provided.

[merks]

I'm really not sure this is a good idea, but the problem keeps cropping up and then the fingers point wildly in different directions...

I picked this range because these are known to exist:

[jonahgraham]

I approve - once it is merged and built I think I will do some upgrade tests (like the ones I do on EPP day, but ahead of time so we have a chance to resolve before M2 publishes).

[merks]

Yes, I'd like to merge this so I can do some testing with the staging repository long ahead of m2.

We might even remove this again if there is a new version of commons-logging 1.3.x with changes that also avoid the problem:

apache/commons-logging#337

[merks]

I re-ran the experiment which previously logged:

[2025-01-23 08:27:16] Collected 3 artifacts for https://download.eclipse.org/efxclipse/runtime-released in 0.74s
[2025-01-23 08:27:17] Installing org.apache.commons.jxpath [1.3.0.v200911051830]
[2025-01-23 08:27:17] Installing org.apache.commons.logging [1.2.0.v20180409-1502]
[2025-01-23 08:27:17] Installing javax.inject [1.0.0.v20091030]
[2025-01-23 08:27:17] Preparing to commit the provisioning operation.

This time I did it for the committers staging product (which includes the EPP common feature) and that logs this:

Collected 1 artifacts for https://download.eclipse.org/efxclipse/runtime-released in 0.187s
Installing org.apache.commons.jxpath [1.3.0.v200911051830]
Installing javax.annotation.jre [1.2.0.201803260600]
Installing javax.inject [1.0.0.v20091030]
Preparing to commit the provisioning operation.
Committing the provisioning operation.

Note the other "updates" to outdated Orbit content coming form the old efxclipse repository.

Of course egit continues to be function well after this harmless "update".

---

If I try to force the IDE to install exactly the broken version:

It fails like this:

  ERROR: org.eclipse.equinox.p2.director code=0 Software being installed: artificial_root 1.0.0.v1737704764849
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: artificial_root 1.0.0.v1737704764849
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; epp.package.committers [4.35.0,5.0.0), filter=(|(&(osgi.arch=aarch64)(|(&(osgi.os=linux)(osgi.ws=gtk))(&(osgi.os=macosx)(osgi.ws=cocoa))(&(osgi.os=win32)(osgi.ws=win32))))(&(osgi.arch=x86_64)(|(&(osgi.os=macosx)(osgi.ws=cocoa))(&(osgi.os=win32)(osgi.ws=win32))))(&(osgi.os=linux)(osgi.ws=gtk)(|(osgi.arch=riscv64)(osgi.arch=x86_64))))
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: artificial_root 1.0.0.v1737704764849
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.apache.commons.logging [1.2.0.v20180409-1502,1.2.0.v20180409-1502]
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: Eclipse IDE for Eclipse Committers 4.35.0.20250123-1501 (epp.package.committers 4.35.0.20250123-1501)
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.eclipse.epp.package.common.feature.feature.group [4.35.0.20250123-1501,4.35.0.20250123-1501]
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: Eclipse Packaging Project Common Feature 4.35.0.20250123-1501 (org.eclipse.epp.package.common.feature.feature.group 4.35.0.20250123-1501)
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.apache.commons.logging [1.2.0.v20151023-1447,1.2.0.v20180409-1502], min=0, max=0

Fortunately we previously improved p2 so that is actually shows the min=0, max=0 so we can see there is a negative requirement preventing installation.

So this appears to be working as intended.

[jonahgraham]

BTW I have tested this too, for example updating eclipse-cpp-2022-12-R-linux-gtk-x86_64.tar.gz to the staging build works fine. 2022-12 included 1.2.0.v20180409-1502 version and after updating to 2025-03 staging the 1.2.0 version is in use.

Thanks Ed for the solution.

For anyone else wondering, this isn't the first time (but maybe it will be the last time :-) that we have to workaround 3rd party library version issues in EPP. A previous example is what was introduced in b7632dc (and removed as part of 711cdb4)