Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

egit breaks when upgrading MWE2 to 2.20 #314

Closed
Bananeweizen opened this issue Nov 18, 2024 · 17 comments
Closed

egit breaks when upgrading MWE2 to 2.20 #314

Bananeweizen opened this issue Nov 18, 2024 · 17 comments

Comments

@Bananeweizen
Copy link

All the egit/jgit related bundles show errors like this in the platform log after upgrading MWE2 from 2.19 to 2.20:

org.osgi.framework.BundleException: Could not resolve module: org.eclipse.egit.ui [991]
  Unresolved requirement: Import-Package: org.eclipse.egit.core.internal.gerrit; version="[7.0.0,7.1.0)"
    -> Export-Package: org.eclipse.egit.core.internal.gerrit; bundle-symbolic-name="org.eclipse.egit.core"; bundle-version="7.0.0.202409031743-r"; version="7.0.0"; x-friends:="org.eclipse.egit.ui"
       org.eclipse.egit.core [987]
         Unresolved requirement: Import-Package: org.eclipse.jgit.lfs; version="[7.0.0,7.1.0)"; resolution:="optional"
         Unresolved requirement: Import-Package: org.eclipse.jgit.transport.http.apache; version="[7.0.0,7.1.0)"
           -> Export-Package: org.eclipse.jgit.transport.http.apache; bundle-symbolic-name="org.eclipse.jgit.http.apache"; bundle-version="7.0.0.202409031743-r"; version="7.0.0"; uses:="org.apache.http.client,  org.eclipse.jgit.transport.http,  org.apache.http.entity,  org.apache.http.client.methods,  javax.net.ssl,  org.eclipse.jgit.util,  org.apache.http"
              org.eclipse.jgit.http.apache [1078]
                Unresolved requirement: Import-Package: org.apache.http.client; version="[4.4.0,5.0.0)"
                  -> Export-Package: org.apache.http.client; bundle-symbolic-name="org.apache.httpcomponents.httpclient"; bundle-version="4.5.14"; version="4.5.14"; uses:="org.apache.http,org.apache.http.auth,org.apache.http.client.methods,org.apache.http.conn,org.apache.http.conn.routing,org.apache.http.cookie,org.apache.http.params,org.apache.http.protocol"
                     org.apache.httpcomponents.httpclient [125]
                       Unresolved requirement: Import-Package: org.apache.commons.logging; version="[1.1.0,1.3.0)"
                Unresolved requirement: Import-Package: org.apache.http.client.config; version="[4.4.0,5.0.0)"
                  -> Export-Package: org.apache.http.client.config; bundle-symbolic-name="org.apache.httpcomponents.httpclient"; bundle-version="4.5.14"; version="4.5.14"; uses:="org.apache.http"

I believe this is caused by adding commons.logging in MWE2, with a minimum version that is not accepted by the egit components: 0e72e40
@cdietrich
Copy link
Member

am not sure if this is the correct place to discuss this.

@cdietrich
Copy link
Member

cdietrich commented Nov 18, 2024 •
edited
Loading

see also #310

eclipse/xtext#3192 (comment)

@Bananeweizen Bananeweizen mentioned this issue Nov 18, 2024
Closed
@cdietrich
Copy link
Member

@merks should we discuss this on cross project dev issues?

afaik its not a singleton so multiple ones should be possible

@merks
Copy link
Contributor

merks commented Nov 18, 2024

I'll do some investigation and comment here a bit later.

One thing I should point out up front is that the only SimRel contribution for MWE was one which is before the changes made to the logging versions:

image

(It's not clear why such a high upper bound was chosen.)

Then there was a release version contributed for RC1. This seems like a poor strategy, especially given all the problems we've had in most recently with wiring problems related to the logging bundles. Ideally you would produce a release after a milestone/rc version of your repository has been used to produce a milestone/rc EPP package such that you have wiggle room. I.e., follow the established processes that have been in place for years. Again this release cycle I see a release produced even before there is an Orbit release, which also caused problems during the previous release cycle.

I would strongly suggest to revisit the current practices that are now known to cause problems, problems that can only be addressed with significant additional effort.

@cdietrich
Copy link
Member

grafik

@cdietrich
Copy link
Member

grafik

@cdietrich
Copy link
Member

grafik

@cdietrich
Copy link
Member

from my pov it was contributed before ?!?

@cdietrich
Copy link
Member

=> from my pov the problem is nobody tests milestones

@merks
Copy link
Contributor

merks commented Nov 18, 2024

Sorry, sorry, indeed September is month 09 not 10. (It's my first day back from vacation.)

Testing installing the current staging version of the DSL EPP packages, I cannot reproduce the problem. EGit functions well in this packages (I can close a repository) and both versions of logging are installed:

image

There's nothing in the error log about wiring problems.

image

Note that I do try to test the "Eierlegende Wollmilchsau" regularly to ensure that everything installs and works reasonably, but it's also nice to have a real vacation once in a blue moon...

@Bananeweizen

Given I can't reproduce the problem, maybe there is more than meets the eye?

@merks
Copy link
Contributor

merks commented Nov 18, 2024 •
edited
Loading

FYI, I tried the Eierlegende Wollmilchsau staging with a GEF classic setup. That has the problem cloning, but that looks like some problem "injected" but docker, unrelated to the problem described here:

java.lang.Exception: java.lang.NoClassDefFoundError: Could not initialize class org.apache.http.conn.ssl.SSLConnectionSocketFactory
	at org.eclipse.oomph.setup.git.impl.GitCloneTaskImpl.perform(GitCloneTaskImpl.java:1033)
	at org.eclipse.oomph.setup.git.impl.GitCloneTaskImpl.perform(GitCloneTaskImpl.java:900)
	at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3869)
	at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil$1.run(SetupTaskPerformer.java:5210)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2457)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2482)
	at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil.performNeededSetupTasks(SetupTaskPerformer.java:5203)
	at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3803)
	at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3778)
	at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3656)
	at org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:592)
	at org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:721)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.apache.http.conn.ssl.SSLConnectionSocketFactory
	at org.eclipse.jgit.transport.http.apache.HttpClientConnectionFactory$HttpClientSession.configure(HttpClientConnectionFactory.java:89)
	at org.eclipse.jgit.transport.http.apache.HttpClientConnectionFactory$HttpClientSession.configure(HttpClientConnectionFactory.java:1)
	at org.eclipse.jgit.transport.TransportHttp.httpOpen(TransportHttp.java:1062)
	at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:651)
	at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:465)
	at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:153)
	at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:105)
	at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1458)
	at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:238)
	at org.eclipse.jgit.api.CloneCommand.fetch(CloneCommand.java:319)
	at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:189)
	at org.eclipse.oomph.setup.git.impl.GitCloneTaskImpl.cloneRepository(GitCloneTaskImpl.java:1433)
	at org.eclipse.oomph.setup.git.impl.GitCloneTaskImpl.perform(GitCloneTaskImpl.java:914)
	... 12 more
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.ExceptionInInitializerError [in thread "Thread-17"]
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.<clinit>(SSLConnectionSocketFactory.java:151)
	at org.mandas.docker.client.builder.BaseDockerClientBuilder.getSchemeRegistry(BaseDockerClientBuilder.java:300)
	at org.mandas.docker.client.builder.jersey.JerseyDockerClientBuilder.createClient(JerseyDockerClientBuilder.java:65)
	at org.mandas.docker.client.builder.BaseDockerClientBuilder.build(BaseDockerClientBuilder.java:269)
	at org.eclipse.linuxtools.internal.docker.core.DockerClientFactory.getClient(DockerClientFactory.java:117)
	at org.eclipse.linuxtools.internal.docker.core.DockerClientFactory.getClient(DockerClientFactory.java:53)
	at org.eclipse.linuxtools.internal.docker.core.DockerConnection.open(DockerConnection.java:273)
	at org.eclipse.linuxtools.internal.docker.core.DefaultTCPConnectionSettingsProvider.getConnectionSettings(DefaultTCPConnectionSettingsProvider.java:32)
	at org.eclipse.linuxtools.internal.docker.core.DefaultDockerConnectionSettingsFinder.getKnownConnectionSettings(DefaultDockerConnectionSettingsFinder.java:210)
	at org.eclipse.linuxtools.docker.core.DockerConnectionManager.lambda$reloadConnections$0(DockerConnectionManager.java:64)
	at java.base/java.lang.Thread.run(Thread.java:1583)

@jonahgraham

This is a strange problem that maybe affects CDT?

I did just also test the CDT staging with the CDT setup and cloning works fine for that, so no worries...

@merks
Copy link
Contributor

merks commented Nov 18, 2024

@cdietrich @Bananeweizen

FYI, whatever the problem here I don't think MWE2 is responsible for restricting the versions of things it uses to suit what EGit needs and even here it's more of a problem with what the 3rd party library providing org.apache.http.client is doing which is beyond everyone' control. Even EGIt provides both versions (with different BSNs) in its update site:

image

So I think this issue should be closed because it's not an issue for which MWE2 is responsible...

@Bananeweizen
Copy link
Author

I'm fine with closing here, and thanks for all that already looked into the issue. I have reproduced the issue in several of my locally existing long-running IDEs (all from custom Oomph setups based on 2024-09). However, I have not yet been able to reproduce this from a fresh download of any of the 2024-09 packages, following the same upgrade routine. So of course it could also be related to additional features being installed by those custom Oomph setups (or even my personal Oomph setup), and it seems reasonable to not waste your time unless I can reproduce this publicly.
As a workaround for our teams I've set a version range for MWE2 as long as I'm still investigating the real root cause.
What worries me a bit is that even reverting installation history to a point before the upgrade doesn't fix the broken state. I haven't experienced such a thing before.

@merks
Copy link
Contributor

merks commented Nov 18, 2024

It's indeed really strange... Can you look at which versions of these two things are installed in the broken IDE?

image

I'm curious about that because it's hard to understand how p2 installed something that can't be wiring because of actually missing exported Java packages. It's not even a usage constraint problem like the last time...

Sometime starting with -clean might therapeutic...

@merks
Copy link
Contributor

merks commented Nov 18, 2024

FYI, these are the details about what strictly requires these two bundles and how they require them, i.e., via package import or via the BSN:

image

@Bananeweizen
Copy link
Author

We had several more people and IDEs that failed with this problem. After lots of experimenting, we found that the problem vanished when we removed the equinox.resolver.batch.timeout property from our Oomph setups. You may or may not remember that setting from the "Eclipse hangs during startup" issues like eclipse-tycho/tycho#213 where we experimented with timeout and batchsize.

@Bananeweizen Bananeweizen closed this as not planned Won't fix, can't repro, duplicate, stale Nov 25, 2024
@merks
Copy link
Contributor

merks commented Nov 25, 2024

I see. Yes, I have a client project where resolution takes "forever" which is really, really annoying during development so using batchsize to help...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@merks @cdietrich @Bananeweizen