Workspace template fails to read files from github in some Eclipse configurations #6431
Comments
|
After additional install testing, the original problem (failed jgit-based github files download with Cannot initialize class error) appears to occur only if: Jgit 7.1.0 is installed That is, if only egit/jgit is installed (not m2e) as described by above comment
....then the problem does not occur. If, however, egit is installed (required by bndtools), and m2e is installed (either via package, explicit install, or via bndtools m2e extension) then the problem described above occurs. Many (most?) of the packages produced by the Eclipse Packaging Project currently (e.g. Java, Committers, others) currently include both m2e and egit. If bndtools 7.1 is installed into any of those packages, then I would predict this same problem to occur. |
|
Quite possibly related. With EGIT 2024-12 I get the anomalies below. I use m2e from 2024-12 releases. The Eclipse configurations shows that I have bntools.api and bbndtools.jareditor installed.
The error log shows java.lang.ExceptionInInitializerError I had to use 2024-09 to add QVTo and MoDisco touches for 2025-03. |
|
This looks like eclipse-orbit/orbit-simrel#40 (comment) |
|
It seems that transitively SimRel has a bad org.apache.commons.logging:1.2.0.v20180409-150 from the old Orbit. While arbitrary Eclipse add-ons may be free to add inconsistent contributions, surely everything in SimRel MUST be compatible? Projects that really need a bad variant should workaround an officious SimRel aggregator by including the bad variant as private internal libraries. (Historical imports from the old Orbit for products that have not been refreshed are surely different versions and so not a problem?) |
|
I did previously explain a workaround for how to exclude/remove the bad variant, but I can't for the life of me find where anymore. So I described it again here for future reference eclipse-orbit/orbit-simrel#40 (comment) I hope never to have to explain the following again; hope dies last. Nothing needs the bad variant, i.e., 1.2.0.v20180409-150. It simply has a higher version so will generally be installed when available in a p2 repository being used during an install or an update. In addition, it will not be downgraded when already installed. Neither SimRel 2024-09 nor 2024-12 contain it so there isn't much that can be done on that end. Note too that the bad variant is only a problem when a newer 1.3.x version is also installed. Here we see both 1.2.x and 1.3.x versions along the things strictly requiring those versions:
Note how org.apache.httpcomponents.httpclient excludes the 1.3.0 version of the package. (Why do they do that?) Looking at all the dependencies org.apache.httpcomponents.httpclient 4.x, I would not hold my breath that this bundle will be eliminated anytime in the foreseeable future:
In any case, it's proven impossible to eliminate all older Orbit content despite all efforts toward that goal: eclipse-simrel/simrel.build#438 If only I could get people to stop including 3rd party bundles in features and use package requirements instead of bundle requirements. In any case, those steps include explicitly excluding, via Exclusion Rules, some outdated versions for problematic ones where the outdated version has a higher version number:
So surely yes, everything in SimRel is compatible with the 1.2.0 version because the officious SimRel aggregator excludes the unwanted variant. |
|
I have checked with the local bndtools Development Environment and I see the mentioned problematic I think it gets pulled in via our Then I check my host Eclipse (Version: 2023-09 (4.29.0) and also Version: 2024-12 (4.34.0)) In both cases I see 
@peterkir Since @merks mentiones Oomph in eclipse-orbit/orbit-simrel#40 (comment) : is this something relevant for our oomph stuff you added recently for bndtools ? @ewillink In eclipse-orbit/orbit-simrel#40 (comment) you mentioned that you got a workaround working. In conclusion:
Any thoughts? |
I did pretty much exactly as @emerks directed; the instructions are pretty precise. My additional eclipse-orbit/orbit-simrel#40 (comment) NBs a couple of impatient mistakes that I made and an observation. All that I might add is that you need to install Oomph Setup SDK from 2024-12 - https://download.eclipse.org/releases/2024-12. |
|
The issue has nothing to do with Oomph; you can just use Oomph to help work around the problem. The fundamental problem is that org.apache.commons.logging:1.2.0.v20180409-1502 installed along with org.apache.commons.commons-logging:1.3.3 just doesn't work. And, as I said, if the 1.2.0.v20180409-1502 is visible in any repo it will tend to be installed in favor of 1.2.0, so best BND not include that it its repository. Also, if anything exactly requires 1.2.0.v20180409-1502 then it definitely will be installed and you cannot exclude it, so best not include that bundle in any feature and best to use package imports with as wide a version range as possible. The problem with this problem is people keep wanting to push the blame somewhere to a single location. So "old Orbit" is to blame for producing poor/bad metadata. Httpclient is to blame for using such a narrow version range. Apache is to blame for making the bundle name for 1.3 different from the bundle name for 1.2. A whole bunch of people are to blame for continuing to use the old httpclient. A whole bunch of people are to blame for not using package imports. If there were a new 1.2.x version created at Maven central, that would avoid the whole problem too, but that will never happen. So I think this problem will never really die... |
@chrisrueger , @scottslewis (and others with that problem) can you please start eclipse with Then type in Also please do:
and for each bundle like perform
and post the output here if possible. |
|
I do not have this problem mentioned by @scottslewis, but maybe for comparison I post my stuff here: 
|
Wouldn't the commons logging project lead be in a position to address? For example, remove from maven central the offending version. I suppose it would be nice to have some OSS industry-wide policy wrt library//dependency deprecation (i.e. 'standards'), but maybe it's time to produce something workable as an OSS dev community so that such cross-org, cross-project, cross-vendor vulnerabilities can at least be addressed in principle. Not a short-term fix, obviously, but probably needed for (e.g.) CSA. |
|
As far as I understand it nothing can ever be removed from maven central. Moreover, we see that this bundle would stop working without 1.2.x, or would need 1.1.x which is an even lower version that 1.2.0.x so would not help solve any problem. A new version of httpclient that didn't exclude 1.3.0 would help stamp out this problem. Note too that the offending version is not the one at maven central but the one that Orbit produced by discarding the OSGi metadata from the one in maven central and replacing it with something else. I think it would be helpful to see the information that @laeubi requested in #6431 (comment). |
I already talked with the httpcomponents people about further improvements and osgi support and basically:
Beside that one might want to blame the OSGi resolver to build an incompatible classpace but without the requested information from the actual problem its hard to guess. |
Then please generate and post here. I've expended my/ECF's time budget on problems caused purely by the inability for other projects to work cooperatively to provide a functioning and secure Eclipse.
Hmmm. Where have I heard this set of responses before? Could it be from (EF and non-EF) projects that the entire Eclipse ecosystem depend upon? Maybe they have a point. FWIW: Eclipse (via ECF filetransfer API) has for 2+ years included an impl of httpclient (5) and for 15+ years now that has exposed a single, stable, reliable, async file transfer API to clients (e.g. p2, oomph at least), AND maintained/updated provider implementations like Apache httpclient 3,4,5, etc. so that conflicts such as this could be easily avoided by Eclipse-based projects and products. |
|
Lack of resource is indeed a pervasive problem, being helpful is not without cost, and even things that are easy don't necessarily get done. It is an imperfect world full of imperfect people. I installed the Eclipse Eierlegende Wollmilchsau and added the following to the installation.setup, saved, and invoked Help -> Perform Setup Tasks:
I believe that doing that for any Eclipse installation will reproduce the problem because it updates the installation to use logging 1.2.0.v20180409-1502. Here is the requested details. The offending detail appears to be the following: That's not surprising given the bounds on the imported export which presume that all 1.x versions will provide a compatible internal implementation:
I wonder if the org.apache.commons package is not also bound to 1.3.0 and if not why not? In any case, this seems a problem that has been waiting to happen since 2018... |
This is most likely wrong and should be something like
First the import is optional (so the resolver can discard this if it is in conflict) what is another strange detail, I don't think optional is forbidden but does not make much sense for a substitution package. Next thing is use clauses, if the exported package do not contain use clauses, then essentially all packages are seen as completely independent and unrelated, that means resolver can (and will!) resolve them eventually to different providers. I'll try to condense a test-case from this maybe then one can tell more details (see also eclipse-equinox/equinox#670). |
|
It was not completely clear to me but if we look here:
Then optional is useful for the last case but I really doubt the author of that information really has this in mind, this will only apply if the export does not match the import and there is no external provider for the package ... I literally can't think of any case where it might be useful and working but it is not forbidden. |
|
I looked further into this and it seems the main issue is that 1.3.4 is not having a use-clause on the package export. I have created LOGGING-198 for this. So if there would be a |
|
Just for reference, there is also this: eclipse-packaging/packages#270 |
|
I'm not sure from where the bad version of commons.logging is coming but we've taken steps to ensure that is impossible to install the bad version in any 2025-03 package: eclipse-packaging/packages#270 (comment) As far as I can tell, there is nothing BND can do to fix this problem, short of what EPP has already done. |
I'm opening this bug here (even though I think the root cause is in egit or other Eclipse projects) because the problem shows up for bndtools 7.1 users that install bndtools 7.1 into eclipse packages or the SDK with git installed.
When creating a new workspace via File->New->Bnd OSGi Workspace
In environments with egit/jgit installed the following error occurs in Preview Changes
Note that the first time, the Preview Page contents are empty with no error message as shown in the previous screenshot, but if the Preview Page will be empty but the shown error message will be present.
Error: Could not initialize class org.apache.http.conn.ssl.SSLConnectionSocketFactory is not from bndtools code, but I believe it's from jgit's usage of apache httpclient 4.5...see below.
Nothing (e.g. stack) is reported to the Eclipse Error view or osgi log. I suspect the reason for this is that in the WorkspacePreviewPage class:
bnd/bndtools.core/src/bndtools/wizards/workspace/WorkspacePreviewPage.java
Line 252 in e5f3bc6
The Exception message is not getting logged and only sets the errorMessage. It would be helpful for debugging this if the Exception caught in WorkspacePreviewPage logged the exception and stack trace.
With configuration...
OS: Windows/x64
Java version: 17
...the problem described above occurs.
While with the Eclipse SDK as base...i.e.
...the problem described above does not occur.
There might be more than one copy of Apache httpclient 4.5.* in the Eclipse Committers package that is causing a class initialization failure in jgit, that results in the exception bubbling up to bndtools 7.1 workspace template when attempting reading from github.
org.apache.http.conn.ssl.SSLConnectionSocketFactory exists in 4.5.* of httpclient, but does is in a different package in httpclient5 (which is now used by Eclipse 4.34 for install update) i.e. org.apache.hc.client5.http.ssl.SSLConnectionSocketFactory.
The text was updated successfully, but these errors were encountered: