fix: restore lombok.config resolution for the Lombok agent

[chagong]

Problem

lombok.config is never applied by jdt.ls. None of the keys take effect — lombok.accessors.chain, lombok.equalsandhashcode.callsuper, lombok.copyableAnnotations, etc. all silently fall back to their defaults, while the same project compiles correctly with javac/Maven.

Reported downstream as redhat-developer/vscode-java#4461 and redhat-developer/vscode-java#4467.

Root cause

Lombok resolves which lombok.config applies to a source file in EclipseAST.getAbsoluteFileLocation0(). ECJ hands it a workspace-relative name such as /myproject/src/main/java/com/example/Main.java, which Lombok maps to a real disk location via ResourcesPlugin.getWorkspace().getRoot().getFile(new Path(path)).getLocationURI().

Lombok's classes are loaded by a ShadowClassLoader whose parent is the bundle class loader that first requested a lombok.* class — the bundle hosting ECJ. Since ECJ was split out into org.eclipse.jdt.core.compiler.batch, that bundle's manifest declares only Export-Package: no Import-Package, no Require-Bundle. So org.eclipse.core.runtime.IPath cannot be loaded, and the workspace-based resolution fails:

NoClassDefFoundError: org/eclipse/core/runtime/IPath

Lombok catches that and falls back to new File(fileName).getAbsoluteFile(), resolving the workspace-relative name against the process working directory. That path does not exist, so FileSystemSourceCache.forUri throws and the resolver returns no configuration at all — every key gets its default.

Change

Adds org.eclipse.jdt.ls.compiler.batch.fragment, a fragment of org.eclipse.jdt.core.compiler.batch contributing:

Import-Package: org.eclipse.core.resources, org.eclipse.core.runtime

This restores class visibility for agents woven into ECJ without modifying the host bundle. The fragment carries no code — it exists purely for its manifest.

Registered in the root pom.xml, both .product files, category.xml, and the three dev .launch configs. The test runtime picks it up via extraRequirements in org.eclipse.jdt.ls.tests/pom.xml.

Test

LombokConfigurationTest imports the new maven/mavenlombokconfig fixture, whose root lombok.config sets lombok.accessors.chain=true, and asserts the generated setter returns the declaring type rather than void. It fails without the fragment:

expected: <Chained> but was: <void>

and passes with it. The test no-ops when jdt.ls.lombok.disabled is set or when the Lombok agent isn't present, matching the existing Lombok tests.

Note for upstream JDT

Any Eclipse-based product weaving an agent into ECJ hits this, not just jdt.ls — the Eclipse IDE included. A DynamicImport-Package or Eclipse-BuddyPolicy: dependent on org.eclipse.jdt.core.compiler.batch would fix it at the source; happy to open an issue against eclipse.jdt.core if that's preferred over carrying the fragment here.

[chagong]

@datho7561 Can you take a look? That CI failure looks like a flaky failure. Can you retry it for me?

[datho7561]

Yeah it looks like a flakey test, I'll rerun it and try to get to reviewing this today.

[datho7561]

Reading through this issue, I think this should be fixed upstream in Lombok instead of doing hacks here to try and get it to work. That's what's been done in the past (See projectlombok/lombok#3347). If lombok wants to access org.eclipse.core.resources from ECJ, it should contribute the hacks necessary to get that working, and based off the previous fix it should be able to do that.

[datho7561]

See https://github.com/projectlombok/lombok/pull/3563/changes for reference maybe? That seems to be specifically targetting jdt.core for loading; we'd need to do org.eclipse.core.resources.

[chagong]

You're right — this belongs upstream in Lombok. The existing fix from projectlombok/lombok#3563 reflects EquinoxBundle.getModuleClassLoader(boolean), which Equinox removed in 8cc615a. Using the standard OSGi Bundle.adapt(BundleWiring.class).getClassLoader() returns the correct loader.

I'll close this PR and move the fix upstream.