redhat-developer / redhat-developer/vscode-java
Problem with multi-module project: classes not on classpath and unresolved imports
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 2.3k
- Forks
- 546
- Avg merge
- 20h 1m
- Merged PRs (30d)
- 11
Description
VS Code Version:
- Version: 1.101.2 (user setup)
- Commit: 2901c5ac6db8a986a5666c3af51ff804d05af0d4
- Date: 2025-06-24T20:27:15.391Z
- Electron: 35.5.1
- ElectronBuildId: 11727614
- Chromium: 134.0.6998.205
- Node.js: 22.15.1
- V8: 13.4.114.21-electron.0
Extensions:
- Extension Pack for Java | Microsoft | microsoft.com | 0.29.2
- Language Support for Java(TM) by Red Hat | Red Hat | redhat.com | 1.43.1
- Debugger for Java | Microsoft | microsoft.com | 0.58.2
- Test Runner for Java | Microsoft | microsoft.com | 0.43.1
- Maven for Java | Microsoft | microsoft.com | 0.44.0
- Project Manager for Java | Microsoft | microsoft.com | 0.24.1
OS:
Windows 11 Business
Java Version:
openjdk version "11.0.10" 2021-01-19
Problem Description:
In a multi-module Maven project with modules that use src or ejbModule as the source folder (not the standard Maven structure), the Java Language Server does not recognize the classes as part of the classpath and shows the error:
<ClassName>.java is not on the classpath of project <project>, only syntax errors are reported.
Some classes fail to resolve imports and show red underlines.
However, if I run mvn clean install, the project and all submodules compile correctly.
What I've already tried:
- Added
"java.project.sourcePaths": ["src"]or["ejbModule"]in the various modules - Cleaned and rebuilt the Java workspace
- Deleted
.vscode,.project,.classpath - Reloaded the window and restarted VS Code
- All dependencies are correctly resolved by Maven (
mvn clean installworks) - Other colleagues using VS Code do not experience this issue with this same project structure
Project structure:
Logs from Output → Java Language Server:
!ENTRY org.eclipse.jdt.ls.core 4 0 2025-07-08 15:39:31.350 !MESSAGE _/oamui/src/com/imnet/oam/web [in oam.ng_d235b972] does not exist !STACK 1 Java Model Exception: Error in Java Model (code 969): _/oamui/src/com/imnet/oam/web [in oam.ng_d235b972] does not exist at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:548) at org.eclipse.jdt.internal.core.PackageFragmentRoot.getUnderlyingResource(PackageFragmentRoot.java:768) at org.eclipse.jdt.internal.core.PackageFragment.getUnderlyingResource(PackageFragment.java:417) at org.eclipse.jdt.internal.core.Openable.getUnderlyingResource(Openable.java:333) at org.eclipse.jdt.internal.core.CompilationUnit.getUnderlyingResource(CompilationUnit.java:1095) at org.eclipse.jdt.ls.core.internal.handlers.BaseDiagnosticsHandler.collectNonJavaProblems(BaseDiagnosticsHandler.java:198) at org.eclipse.jdt.ls.core.internal.handlers.BaseDiagnosticsHandler.endReporting(BaseDiagnosticsHandler.java:149) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.reportProblems(ReconcileWorkingCopyOperation.java:157) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:126) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:751) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:816) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1431) at org.eclipse.jdt.ls.core.internal.handlers.BaseDocumentLifeCycleHandler.publishDiagnostics(BaseDocumentLifeCycleHandler.java:338) at org.eclipse.jdt.ls.core.internal.handlers.BaseDocumentLifeCycleHandler.publishDiagnostics(BaseDocumentLifeCycleHandler.java:301) at org.eclipse.jdt.ls.core.internal.handlers.BaseDocumentLifeCycleHandler$PublishDiagnosticJob.run(BaseDocumentLifeCycleHandler.java:798) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) !SUBENTRY 1 org.eclipse.jdt.core 4 969 2025-07-08 15:39:31.350 !MESSAGE _/oamui/src/com/imnet/oam/web [in oam.ng_d235b972] does not exist
Steps to reproduce:
- Open the project root in VS Code
- Wait for indexing to complete
- Open a Java class in
srcorejbModuleof a module - See the classpath error
Thanks for your help!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce from the project root using a multi-module Maven project with modules containing src or ejbModule, then inspect the Java Language Server output for the reported missing-resource path. Compare the configured source paths with the module layout and verify the result by opening affected classes. Done means classes are on the project classpath, imports resolve, and the classpath diagnostic no longer appears.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100