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.

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

Xtext installation breaks org.apache.commons.logging functionality of Eclipse (breaks Eclipse) #3279

Open
maxkratz opened this issue Dec 4, 2024 · 35 comments

Comments

@maxkratz
Copy link

maxkratz commented Dec 4, 2024

The latest stable release of Xtext breaks some of the Eclipse functionalities, resulting in a non-functioning IDE.

Steps to reproduce:

  • Download Eclipse Modeling Framework v2024-09, e.g., from here https://ftp.fau.de/eclipse/technology/epp/downloads/release/2024-09/R/
  • Start Eclipse
  • Click on Help -> Install new Software -> paste the text update site (http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/) into the Work with: field
  • Press Enter.
  • Select the package Xtext and click on the button Next >
  • (Wait until Eclipse determines all necessary packages, etc.)
  • Press the button Next >.
  • (Wait again ...)
  • Press the button Next > again.
  • Accept the license agreements.
  • Click on Finish.
  • Wait until the installation has been finished and close the IDE.
  • Start Eclipse via the CLI: ./eclipse -noSplash -consoleLog
  • Click on File -> Import... -> Team -> Team Project Set -> paste a PSF file, e.g., this link and proceed with the import.

See the error log from the console:

!ENTRY org.eclipse.ui 4 0 2024-12-04 16:26:16.230
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.ExceptionInInitializerError
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.<clinit>(SSLConnectionSocketFactory.java:151)
	at org.eclipse.jgit.transport.http.apache.HttpClientConnectionFactory$HttpClientSession.configure(HttpClientConnectionFactory.java:81)
	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.egit.core.op.CloneOperation.run(CloneOperation.java:194)
	at org.eclipse.egit.core.internal.ProjectReferenceImporter.cloneIfNecessary(ProjectReferenceImporter.java:146)
	at org.eclipse.egit.core.internal.ProjectReferenceImporter.run(ProjectReferenceImporter.java:104)
	at org.eclipse.egit.core.GitProjectSetCapability$1.run(GitProjectSetCapability.java:122)
	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.egit.core.GitProjectSetCapability.addToWorkspace(GitProjectSetCapability.java:118)
	at org.eclipse.team.internal.ui.ProjectSetImporter.importProjectSet(ProjectSetImporter.java:129)
	at org.eclipse.team.internal.ui.ProjectSetImporter.importProjectSetFromString(ProjectSetImporter.java:76)
	at org.eclipse.team.internal.ui.wizards.ImportProjectSetOperation.runForStringContent(ImportProjectSetOperation.java:82)
	at org.eclipse.team.internal.ui.wizards.ImportProjectSetOperation.run(ImportProjectSetOperation.java:98)
	at org.eclipse.team.internal.ui.actions.ProgressDialogRunnableContext.lambda$2(ProgressDialogRunnableContext.java:95)
	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.team.internal.ui.actions.ProgressDialogRunnableContext.lambda$1(ProgressDialogRunnableContext.java:93)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:124)
Caused by: org.apache.commons.logging.LogConfigurationException: The chosen LogFactory implementation does not extend LogFactory. Please check your configuration. (Caused by java.lang.ClassCastException: The application has specified that a custom LogFactory implementation should be used but Class 'org.apache.commons.logging.impl.LogFactoryImpl' cannot be converted to 'org.apache.commons.logging.LogFactory'. The conflict is caused by the presence of multiple LogFactory classes in incompatible classloaders. Background can be found in http://commons.apache.org/logging/tech.html. If you have not explicitly specified a custom LogFactory then it is likely that the container has set one without your knowledge. In this case, consider using the commons-logging-adapters.jar file or specifying the standard LogFactory from the command line. Help can be found @http://commons.apache.org/logging/troubleshooting.html.)
	at org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:1154)
	at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:960)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
	at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:957)
	at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:624)
	at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655)
	at org.apache.http.conn.ssl.AbstractVerifier.<init>(AbstractVerifier.java:61)
	at org.apache.http.conn.ssl.AllowAllHostnameVerifier.<init>(AllowAllHostnameVerifier.java:44)
	at org.apache.http.conn.ssl.AllowAllHostnameVerifier.<clinit>(AllowAllHostnameVerifier.java:46)
	... 28 more
Caused by: java.lang.ClassCastException: The application has specified that a custom LogFactory implementation should be used but Class 'org.apache.commons.logging.impl.LogFactoryImpl' cannot be converted to 'org.apache.commons.logging.LogFactory'. The conflict is caused by the presence of multiple LogFactory classes in incompatible classloaders. Background can be found in http://commons.apache.org/logging/tech.html. If you have not explicitly specified a custom LogFactory then it is likely that the container has set one without your knowledge. In this case, consider using the commons-logging-adapters.jar file or specifying the standard LogFactory from the command line. Help can be found @http://commons.apache.org/logging/troubleshooting.html.
	at org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:1108)
	... 36 more

Without the installation of Xtext, the import functions as expected.

@cdietrich
Copy link
Contributor

I don’t know how we should solve this. What is your proposal.

see also eclipse-mwe/mwe#314

@maxkratz
Copy link
Author

maxkratz commented Dec 5, 2024

Currently, I don't have any clue how to fix it.

Besides eclipse-mwe/mwe#314, this also breaks some other packages like the Darkest Dark Theme.
It seems to me that there will be even more packages (relying on org.apache.commons.logging) that are broken with the recent MWE2 version.

This is a screenshot of an error shown when using the theme together with the latest Xtext/MWE2 version simultaneously.

Screenshot from 2024-12-05 07-20-37

@LorenzoBettini
Copy link
Contributor

I don't understand: is Xtext the only one that requires the new commons-logging? I thought we switched to the new bundle because that was the way in the new release of simrel...

@cdietrich
Copy link
Contributor

@LorenzoBettini
Copy link
Contributor

Ok, but who's doing the wrong thing? Should the others use the new bundle or should we use the old one?

@cdietrich
Copy link
Contributor

From my pov we do the right thing
Somebody decided to drop the old thing from orbit

@maxkratz
Copy link
Author

maxkratz commented Dec 5, 2024

Do I understand the issue correctly?

  • Eclipse Modeling 2024-09 and 2024-12 ship with a plug-in org.apache.commons.logging_v1.2.0.jar
  • Officially, the dependency is called org.apache.commons.commons-logging as it can be seen here https://mvnrepository.com/artifact/commons-logging/commons-logging/1.2, so the naming of the dependency shipped with the Eclipse IDE is not correct.
  • To avoid using a dependency on the "old" (and strictly speaking "incorrect") variant org.apache.commons.logging, Xtext/MWE2 ships its own dependency org.apache.commons.commons-logging in v1.3.4 per eclipse-mwe/mwe@0e72e40 (hence, it is also more up to date).
  • This produces a clash between both versions since they export the same namespace in Java ... (or something similar?)

Did I understand the problem correctly?

I have two additional questions: How/Why is the initial shipped dependency org.apache.commons.logging in the Eclipse IDE incorrect? Where does this "other" name come from?

@cdietrich
Copy link
Contributor

no we ship not our one. we ship this one

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2024-12/

grafik

@cdietrich
Copy link
Contributor

i dont know where the old 2018 comes from.

@cdietrich
Copy link
Contributor

and yes we want to use the correct bundle sym. name

@cdietrich
Copy link
Contributor

see also the original ones:
See #3192 and #3203

@cdietrich
Copy link
Contributor

#3127

@maxkratz
Copy link
Author

maxkratz commented Dec 6, 2024

i dont know where the old 2018 comes from.

If I understand it correctly, the "old" apache commons logging may be a transitive dependency from egit/jgit:

org.osgi.framework.BundleException: Could not resolve module: org.eclipse.mylyn.github.ui [554]
  Unresolved requirement: Import-Package: org.eclipse.mylyn.internal.github.core; version="[6.2.0,7.0.0)"
    -> Export-Package: org.eclipse.mylyn.internal.github.core; bundle-symbolic-name="org.eclipse.mylyn.github.core"; bundle-version="6.6.0.v20241002-1142"; version="6.2.1"; x-friends:="org.eclipse.mylyn.github.ui"
       org.eclipse.mylyn.github.core [552]
         Unresolved requirement: Require-Bundle: org.eclipse.egit.core; bundle-version="6.2.0"
           -> Bundle-SymbolicName: org.eclipse.egit.core; bundle-version="7.1.0.202411261347-r"; singleton:="true"
              org.eclipse.egit.core [205]
                Unresolved requirement: Import-Package: org.eclipse.jgit.lfs; version="[7.1.0,7.2.0)"; resolution:="optional"
                Unresolved requirement: Import-Package: org.eclipse.jgit.transport.http.apache; version="[7.1.0,7.2.0)"
                  -> Export-Package: org.eclipse.jgit.transport.http.apache; bundle-symbolic-name="org.eclipse.jgit.http.apache"; bundle-version="7.1.0.202411261347-r"; version="7.1.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 [518]
                       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 [94]
                              Unresolved requirement: Import-Package: org.apache.commons.logging; version="[1.1.0,1.3.0)"

@maxkratz
Copy link
Author

maxkratz commented Dec 6, 2024

Oh, and it appear that it is also a transitive dependency from Eclipse itself:

org.osgi.framework.BundleException: Could not resolve module: org.eclipse.userstorage [813]
  Unresolved requirement: Import-Package: org.apache.http.client; version="[4.3.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 [94]
         Unresolved requirement: Import-Package: org.apache.commons.logging; version="[1.1.0,1.3.0)"
  Unresolved requirement: Import-Package: org.apache.http.auth; version="[4.3.0,5.0.0)"
    -> Export-Package: org.apache.http.auth; bundle-symbolic-name="org.apache.httpcomponents.httpclient"; bundle-version="4.5.14"; version="4.5.14"; uses:="org.apache.http,org.apache.http.config,org.apache.http.params,org.apache.http.protocol,org.ietf.jgss"

	at org.eclipse.osgi.container.Module.start(Module.java:493)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:2102)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:143)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2093)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2033)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1996)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1912)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:341)

@LorenzoBettini
Copy link
Contributor

@cdietrich if it's a transitive dependency of egit or Eclipse itself then the old bundle must be available from the main eclipse P2 site, independently from orbit. Cc @merks

@maxkratz
Copy link
Author

maxkratz commented Dec 6, 2024

It seems others also have the same problem eclipse-orbit/orbit-simrel#40

@merks
Copy link
Contributor

merks commented Dec 6, 2024

It’s apparently a bad older orbit bundle that breaks things with this as a way to exclude it

eclipse-orbit/orbit-simrel#40 (comment)

This is not an issue that xtext must fix, in my opinion.

@maxkratz
Copy link
Author

maxkratz commented Dec 6, 2024

This is not an issue that xtext must fix, in my opinion.

You are correct. As I learned since opening this issue, the problem goes deeper not just affecting Xtext/MWE2.

@cdietrich
Copy link
Contributor

cdietrich commented Dec 6, 2024

maybe we should ditch the xtext composite site
https://eclipse.dev/Xtext/download.html

or check if we can scrape old mwe versions from there
but i dont know what e.g regenerates the composite content here
https://download.eclipse.org/modeling/emft/mwe/updates/releases/

@szarnekow
Copy link
Contributor

Having only the most recent release on the composite might indeed be an option

@cdietrich
Copy link
Contributor

yes but aint this what we already do here
https://download.eclipse.org/modeling/tmf/xtext/updates/composite/marketplace/
does?

(maybe we should ditch xpand from there)

@LorenzoBettini
Copy link
Contributor

It’s apparently a bad older orbit bundle that breaks things with this as a way to exclude it

eclipse-orbit/orbit-simrel#40 (comment)

This is not an issue that xtext must fix, in my opinion.

@merks but what about a target platform? If org.apache.httpcomponents.httpclient requires it:

 Unresolved requirement: Import-Package: org.apache.commons.logging; version="[1.1.0,1.3.0)"

how can this be solved?

@merks
Copy link
Contributor

merks commented Dec 19, 2024

Given that both the orbit and simrel repos for 2024-12 have that iu and the iu that satisfies its requirements present, include one of those repos and its ius in your target platform.

@merks
Copy link
Contributor

merks commented Dec 19, 2024

I’m surprised to see this issue still open and still kicking. I thought this horse was flogged to death already.

@LorenzoBettini
Copy link
Contributor

Both ius are in the target platform, but as shown above the old one is not resolved when I run the runtime instance..

@merks
Copy link
Contributor

merks commented Dec 19, 2024

Both ius are in the target platform, but as shown above the old one is not resolved when I run the runtime instance..

I don’t know what is in “the target platform” and I don’t know what “both” refer to. But if something doesn’t resolve then both the iu with the requirement (that is missing) and the iu that provides it are not in that target platform, or in the launched runtime. I can assure you, they are in orbit and simrel, and when all simrel ius are installed in an installation everything resolves.

Probably the problem is that the question and the context are vague.

@cdietrich
Copy link
Contributor

We still have the composite update site
Linked and maintained on our website
That has the 1.2.0.2018 and the 1.2.0 which leads to p2 updating to the 2018 if it is used

@merks
Copy link
Contributor

merks commented Dec 20, 2024

It's really the composite from hell isn't it? I try to load it in the repository explorer and must wait patiently; it has content even from 2011 or maybe even older. I wouldn't recommend this URL for a target platform. In any case, the explorer says it does not have 1.2.0:

image

@cdietrich
Copy link
Contributor

yes but my understanding of the problem is

  • eclipse has 1.2.0 installed
  • someone installs xtext from the composite
  • 1.2.0.2018 get installed as update + 1.3 for xtext

@maxkratz
Copy link
Author

yes but my understanding of the problem is

  • eclipse has 1.2.0 installed
  • someone installs xtext from the composite
  • 1.2.0.2018 get installed as update + 1.3 for xtext

This is also my understanding.

(IIRC, this problem also occurs with other update sites, not just the Xtext one)

@merks
Copy link
Contributor

merks commented Dec 20, 2024

Yes, that problem is clear, but I believe we've concluded Xtext can't fix that. In any case, asking "what about the target platform" is digression #3279 (comment) and one that I cannot answer.

@cdietrich
Copy link
Contributor

yes. but it kept this open to discuss in which way to abandon the composite site.
it might have been a good idea in a time where eclipse had a few releases a year and Xtext had 10

@merks
Copy link
Contributor

merks commented Dec 20, 2024

Yes, I imagine most folks just want something that points to the latest, not everything released in the past decade...

@LorenzoBettini
Copy link
Contributor

Sorry for not being clear :)

With "in the target platform" I meant the target platform of the development workspace. Such a target platform contains both commons-logging 1.3.4 and the old commons.logging 1.2.0 bundles.

However, I still get the above error when I start an Eclipse runtime from the development workspace, e.g., when running plugin tests. The same problem breaks my SWTBot tests in the Tycho build.

Just to be clear, I'm NOT using the Xtext composite site: I point to the latest p2 site of Xtext.

I'll try to investigate the problem further.

@LorenzoBettini
Copy link
Contributor

I found the culprit!

I'm not using composite update sites in my .target file. Still, the Epsilon update site https://download.eclipse.org/epsilon/updates/2.5/ has repository references pointing to old Orbit sites, and the wrong org.apache.commons.logging 1.2.0.v20180409-1502 was automatically taken from there.

Pinning the version

<unit id="org.apache.commons.logging" version="1.2.0"/>
<repository location="https://download.eclipse.org/releases/2024-12" />

solved the problem.

agarciadom added a commit to eclipse-epsilon/epsilon that referenced this issue Jan 3, 2025
Apparently, the version of the Commons Logging bundle we were using
has some issues, and it's better to use the one from the 2024-12
simrel:

eclipse-xtext/xtext#3279 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants