Repository navigation
Description
I have some difficulties understanding what really happens when the Java Language Server starts upon opening my project on VS Code and when I save a modified .java file afterward.
My question concerns specifically the building of the project, and I'm asking it because I've witnessed behavior that I couldn't quite explain.
My project is a Maven project and thus, has a pom.xml file. In this file, I use some plugins in the <build> node that do some heavy work (in my case, installing npm dependencies for my frontend and building it).
<!-- An excerpt of my pom.xml file -->
<?xml version="1.0" encoding="UTF-8" ?>
<project /* ... */>
<build>
/* ... */
<plugins>
<plugin>
<groupId>com.github.eirslett</groupId>
<artifactId>frontend-maven-plugin</artifactId>
<version>1.9.1</version>
<executions>
<execution>
/* install nodejs and npm */
</execution>
<execution>
/* npm ci */
</execution>
<execution>
/* npm run build */
</execution>
</executions>
</plugin>
/* other plugins */
</plugins>
/* ... */
</build>
</project>When I open the project with VS Code, the Java Language Server starts and eventually builds the project. This build phase takes a hefty amount of time to complete but envetually does so. After that, each time I save a .java file, the Java Language Server hops in and starts building the project again (as it is somewhat expected). This build also takes a huge amount of time before completing.
When commenting the <plugin> node in my `pom.xml that do the heavy work, the building of the project runs incredibly faster.
Of this, I've come to the conclusion that the Java Language Server detects that I'm using a Maven project thanks to the presence of the pom.xml file and delegates the building of the project to M2Eclipse which, in turn, does something like mvn compile, meaning that each build will execute all the goals registered on the <build> node.
Am I right in this assertion? And if so, would there be any way to compile the project as a "simple" Java Application (something like IntelliJ's Application configuration)?
I know that I could use Maven profiles to scope the execution of those plugins' goals, and prevent their execution when developping but I'd like to be sure to understand what is happening under the hood.
Environment
- Operating System: WSL
- JDK version: 11
- Visual Studio Code version: 1.43.2
- Java extension version: 0.59.0
Metadata
Metadata
Assignees
Type
Projects
- StatusShow more project fieldsDone
Activity
zoily commentedon Jun 20, 2024
Please give an answer
robstryker commentedon Oct 29, 2026
@shin19991207 Can you answer this old question, just so we have it documented? Then you can close the issue :)
shin19991207 commentedon Nov 3, 2026
When you open a Maven project with vscode-java, the Java language server recognizes the Maven project and uses m2e to configure its dependencies and classpath. With automatic building enabled, saving a Java file usually triggers an incremental workspace build. Eclipse’s Java builder compiles the affected sources, and selected Maven plugin goals may also run. This does not simply invoke
mvn compileon every save.For
frontend-maven-plugin1.9.1, its bundled mappings enable thenpmgoal during incremental builds. The goal’s implementation normally skips launching npm whenpackage.jsonis unchanged and m2e can track it within the Maven module.However, if the plugin’s
workingDirectorypoints outside that module, m2e cannot track the externalpackage.jsonthrough the module’s resource changes. Its fallback treats the file as potentially changed, so npm can run on every Java save. For example, if you have a project structure similar to:This can happen when
backend/pom.xmlconfiguresworkingDirectoryas${project.basedir}/../frontend. Your POM excerpt doesn't include that configuration though, so I cannot confirm whether this explains your particular slowdown.You can exclude the expensive executions from IDE builds. For example, add
<?m2e ignore?>inside each frontend<execution>you want m2e to skip (see https://eclipse.dev/m2e/documentation/release-notes-17.html). Maven profiles are another option.