-
Notifications
You must be signed in to change notification settings - Fork 322
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
Comments
I don’t know how we should solve this. What is your proposal. see also eclipse-mwe/mwe#314 |
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. This is a screenshot of an error shown when using the theme together with the latest Xtext/MWE2 version simultaneously. |
I don't understand: is Xtext the only one that requires the new |
Ok, but who's doing the wrong thing? Should the others use the new bundle or should we use the old one? |
From my pov we do the right thing |
Do I understand the issue correctly?
Did I understand the problem correctly? I have two additional questions: How/Why is the initial shipped dependency |
no we ship not our one. we ship this one https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2024-12/ |
i dont know where the old 2018 comes from. |
and yes we want to use the correct bundle sym. name |
If I understand it correctly, the "old" apache commons logging may be a transitive dependency from egit/jgit:
|
Oh, and it appear that it is also a transitive dependency from Eclipse itself:
|
@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 |
It seems others also have the same problem eclipse-orbit/orbit-simrel#40 |
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. |
You are correct. As I learned since opening this issue, the problem goes deeper not just affecting Xtext/MWE2. |
maybe we should ditch the xtext composite site or check if we can scrape old mwe versions from there |
Having only the most recent release on the composite might indeed be an option |
yes but aint this what we already do here (maybe we should ditch xpand from there) |
@merks but what about a target platform? If
how can this be solved? |
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. |
I’m surprised to see this issue still open and still kicking. I thought this horse was flogged to death already. |
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. |
We still have the composite update site |
yes but my understanding of the problem is
|
This is also my understanding. (IIRC, this problem also occurs with other update sites, not just the Xtext one) |
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. |
yes. but it kept this open to discuss in which way to abandon the composite site. |
Yes, I imagine most folks just want something that points to the latest, not everything released in the past decade... |
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. |
I found the culprit! I'm not using composite update sites in my 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. |
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)
The latest stable release of Xtext breaks some of the Eclipse functionalities, resulting in a non-functioning IDE.
Steps to reproduce:
Help
->Install new Software
-> paste the text update site (http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/) into theWork with:
fieldXtext
and click on the buttonNext >
Next >
.Next >
again.Finish
../eclipse -noSplash -consoleLog
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:
Without the installation of Xtext, the import functions as expected.
The text was updated successfully, but these errors were encountered: