Eclipse >= 2024-03: Solution for "The type x.y.z cannot be resolved. It is indirectly referenced from required type a.b.c"

TIPS
1

In case anyone stumbles over the following error when using Eclipse with bndtools:

After upgrading my bnd workspace from Eclipse <= 2023-12 to Eclipse 2024-03 our code suddenly did not compile anymore in Eclipse.

The Problems view showed a red error like The type org.apache.commons.logging.Log cannot be resolved. It is indirectly referenced from required type org.springframework.dao.support.DaoSupport

I reported the problem as part of this Github issue which seemed related: StringConcatFactory can not be resolved · Issue #1842 · eclipse-jdt/eclipse.jdt.core · GitHub

Solution

After some back and forth the solution was this:

In my case I had to add the dependency org.apache.commons.logging to the -buildpath in bnd.bnd of the bundle where the error was reported.

The reason was the compiler in newer Eclipse behaves different related to indirect references and treats it as a built-path error.

I had a class which inherted from a 3rd-party class. This parent class had a protected member field which had a dependency to org.apache.commons.logging.

/** Logger available to subclasses. */
	protected final Log logger = LogFactory.getLog(getClass());

For bnd / OSGI this no problem because we have org.apache.commons.logging in our repository and -importpackage: * fetches this.

But org.apache.commons.logging was not in our -buildpath because our code did not directly reference it… but indirectly because of the protected Logger from the we inherited from. Wasn’t a problem in the past… but newer Eclipse >= 2024-03 behaves different.

Posted my solution here too in case anybody interested in the full discussion.

Hope this saves some trouble if you come across the same thing.

2

This is annoying, but I have to admit that I like it. I have seen similar errors but usually when I build with gradle. I always found it annoying, that eclipse is not complaining there, even if it should.

1 Like
3

Yeah, here it is the other way round. CLI / gradle build is not complaining but Eclipse complains (suddenly).
I admit I like the “stricter is better” too but the different behaviour between Eclipse with bndtools and CLI can cause confusion.

4

Should we add a quickfix?

5

Is this possible at this place? The error happens during compilation , so there is not .jar when this happens. Can bndtools react to this?

But yes, if there is something bndtools can do, then it would help. Currently bndtools development uses an older Eclipse afaik. To reproduce this we would need to use at least 2024-03. Not sure what needs to be done for this.