Closed merks closed 4 months ago
Haven't seen this. Which MANIFEST.MF is this? egit.core? That should not need slf4j. And it should not be necessary to add transitive dependencies in package imports.
It's this one:
/org.eclipse.egit.core/META-INF/MANIFEST.MF
Perhaps some JDT oddity. Do you really have all the latest 2024-06 stuff installed?
No, I have not. I'll see if I can reproduce with a fresh install. But:
But didn't you have such an issue a while ago already, and it disappeared then? I remember having made that comment about JGit encapsulationg the Apache MINA SSHD interfaces already... found it: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/1968#issuecomment-2046831071
I just fix it in my workspace modifying the MANIFEST.MF and then I don't check that in. I know this is a hack, which is why I don't create a PR to check in the hack. Anyway, there is no rush...
Fresh installs (Eclipse for Committers) on Windows:
Changing the MANIFEST.MF as indicated above would be wrong. slf4j.Logger
is referenced in a private static final field in the FileRepository
superclass, which is subclassed in EGit. HostConfigEntryResolver
is referenced in a private final field in org.eclipse.jgit.transport.sshd.SshdSessionFactory
, which is also subclassed.
I don't know why this occurs. To me this looks like a bug in JDT.
Yes, that's exactly my experience! And it's really annoying. Of course someone will want a test case, but that's not a trivial exercise. 😱
@stephan-herrmann
Any ideas how we might boil down a test case? Just using the Oomph setup reproduces it quickly...
Don't know. The common denominator in these two cases seems to be:
private final
or private static final
field referencing X.The presence or absence of explicit constructors might also have an effect.
It is apparently a known problem: https://github.com/eclipse-jdt/eclipse.jdt.core/issues/543 .
Wow, you're very awesome. Oh dear though. 😢
The common denominator in these two cases seems to be:
Of course I'm unable to reproduce it with a small test with just these constructs. So I guess the reproducer for JDT would be to use the EGit Oomph setup.
So we have:
MANIFEST.MF
is needed and used at runtime, and should not have these extra package imports.I would suggest to work around this bug not by changing MANIFEST.MF
but by adding to file build.properties
additional.bundles = slf4j.api,\
org.apache.sshd.osgi
Either manually, or via the PDE Manifest editor:
That would be a work-around that we could merge. build.properties
is really only for building and is not included in the binary artifact. It leaves MANIFEST.MF
unchanged, and thus does not affect the OSGi bundle classloader's classpath, and moreover the change does exactly what JDT needs to avoid this bug: it places these two bundles on the classpath used for compiling.
I had the same thought but was hunting for extra classpath which involved jars. I forgot about this one, which I do use in EMF too. I think we can all agree this is a good idea. 🏅 There is a tiny potential it could mask some real problem, but we must move forward...
I notice additionally that both slf4j.api and org.apache.sshd.osgi:
[WARNING] [6d69866b-71ce-4fad-b276-d52c5c67aa6f][extension>org.eclipse.tycho:tycho-maven-plugin:4.0.6] No digest algorithm is available to verify download of osgi.bundle,org.apache.sshd.osgi.source,2.12.1.
So another condition for reproducing the JDT bug is probably:
Unclear, though, why this only occurs since 2024-03. Perhaps something in PDE and the way it sets up its compilation classpath changed? (Don't see anything, though. There was a refactoring in that area, but it occurred before 2023-12.)
Also unclear: why does compilation work in maven tycho? Does it manage to pick up the valid OSGi source bundle from the JGit repo all the same? (Mvn command line: mvn clean install -DskipTests -Djgit-site=https://repo.eclipse.org/content/unzip/snapshots.unzip/org/eclipse/jgit/org.eclipse.jgit.repository/6.10.0-SNAPSHOT/org.eclipse.jgit.repository-6.10.0-SNAPSHOT.zip-unzip/
.)
I'm a little skeptical that lack of or presence of source bundles makes a difference. I don't expect JDT to be looking at sources at all for things in the target platform for compilation purposes. I expect those are only useful as source attachments while debugging or for mining Javadoc. But who knows.
What you say about the source jars not being proper OSGi bundle is true and it would seem that m2e is wrapping those because I see this in the orbit p2 repository artifacts:
Gerrit change 1195191 adds the two bundles to the build classpath.
Gerrit change 1195191 is merged.
Version
6.10.0
Operating System
Linux/Unix, MacOS, Windows
Eclipse version
2024-06
Bug description
Without these changes:
I see these errors:
Actual behavior
The Oomphed workspace has errors with the latest installed tools.
Expected behavior
An error free workspace.
Relevant log output
No response
Other information
No response