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

[maxkratz]

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]

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

see also eclipse-mwe/mwe#314

[maxkratz]

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.

[LorenzoBettini]

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]

eclipse-mwe/mwe#314 (comment)

[LorenzoBettini]

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

[cdietrich]

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

[maxkratz]

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]

no we ship not our one. we ship this one

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

[cdietrich]

i dont know where the old 2018 comes from.

[cdietrich]

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

[cdietrich]

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

[cdietrich]

#3127

[maxkratz]

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]

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]

@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]

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

[merks]

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]

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]

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]

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

[cdietrich]

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)