Bug about maven sub module same name!

[sincebyte]

I made a multi-module Maven project archetype, and then use it to create 2 another projects, SRM project and CRM Project. SRM and CRM projects both have the same submodule name, they are api, biz, dao, service

The 2 projects structure is as follows：

center-srm         ├     center-crm
├── api            │     ├── api
│   └── pom.xml    ├     │   └── pom.xml
├── biz            │     ├── biz
│   └── pom.xml    ├     │   └── pom.xml
├── dao            │     ├── dao
│   └── pom.xml    ├     │   └── pom.xml
├── service        │     ├── service
│   └── pom.xml    ├     │   └── pom.xml
└── pom.xml        │     └── pom.xml

The artifactId of each pom.xml in the project is equal to the name of the folder to which it belongs，I use groupId to differentiate. For example the center-srm/api/pom.xml，Declare itsself like this:

    <groupId>com.center.srm</groupId>
    <artifactId>api</artifactId>
    <version>0.1.0-SNAPSHOT</version>

For example the center-crm/api/pom.xml，Declare itsself like this:

    <groupId>com.center.crm</groupId>
    <artifactId>api</artifactId>
    <version>0.1.0-SNAPSHOT</version>

Something went wrong when the two projects were placed together in one jdt ide. That is, only one project can provide language services, and the other cannot.

By observing the .project files of SRM and CRM 2 projects, I found them to be almost the same, except for projectDescription.filteredResources.filter.id

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
	<name>api</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
		<buildCommand>
			<name>org.eclipse.jdt.core.javabuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.eclipse.m2e.core.maven2Builder</name>
			<arguments>
			</arguments>
		</buildCommand>
	</buildSpec>
	<natures>
		<nature>org.eclipse.jdt.core.javanature</nature>
		<nature>org.eclipse.m2e.core.maven2Nature</nature>
	</natures>
	<filteredResources>
		<filter>
			<id>1681288056880</id>
			<name></name>
			<type>30</type>
			<matcher>
				<id>org.eclipse.core.resources.regexFilterMatcher</id>
				<arguments>node_modules|.metadata|archetype-resources|META-INF/maven|__CREATED_BY_JAVA_LANGUAGE_SERVER__</arguments>
			</matcher>
		</filter>
	</filteredResources>
</projectDescription>

I tried changing the folder name of the submodule to make SRM and CRM different, Of course, it also includes the artifactId of modifying the pom.xml. And then the problem is solved.

Are we need to have different names for maven's submodules to provide language services, even though they are located in different project directories? Something should go wrong, right?

[rgrunber]

This seems like the same problem as https://github.com/eclipse/eclipse.jdt.ls/issues/2017 & https://github.com/eclipse/eclipse.jdt.ls/issues/844 , which we expect to have fixed in the 1.22.0 (upcoming) release of JDT-LS. What client are you using ?

You're right though. For some time, we configured project names using only the artifactId, which led to such issues.

[sincebyte]

The client which I use is Emacs lsp-java， jdt-language-server-1.7.0-202112161541，I'll upgrade and try

[sincebyte]

could u help me ? lsp start up failed when I upgrade jdt to lasest snapshot version jdt-language-server-1.22.0-202304130326 https://github.com/emacs-lsp/lsp-java/issues/428 jdt-language-server-1.22.0-202304130326.tar.gz zulu17.40.19-ca-fx-jdk17.0.6-macosx_aarch64.tar.gz

[sincebyte]

the error:

2023年4月14日 下午11:46:02 Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".
Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @3093d0d2
java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @3093d0d2
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
	at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.overrideLoadResult(ModuleClassLoader.java:86)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
	at org.eclipse.jdt.internal.compiler.parser.Parser.endParse(Parser.java:11979)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13180)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13407)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13364)
	at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:11750)
	at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:851)
	at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:394)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:448)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:426)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:379)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:214)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:311)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:79)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:273)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1020)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:247)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:392)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:395)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:506)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:454)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:536)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:196)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:289)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

[rgrunber]

I would have a look at https://github.com/eclipse/eclipse.jdt.ls/wiki/Running-the-JAVA-LS-server-from-the-command-line and also https://github.com/eclipse/eclipse.jdt.ls/blob/42f399555a9c638a9892ac67e63470ec907db7a1/org.eclipse.jdt.ls.product/scripts/jdtls.py#L98-L99 . Certain options like --add-opens are probably needed.

[sincebyte]

I see ,it is due to the fact that lombok is not supported.

"-javaagent:~/.doom.d/neoemacs/lombok.jar",

remove this custom option or upgrade my lombok.jar , hereby jdt works well

[sincebyte]

Upgrade jdtl to jdt-language-server-1.22.0-202304131553.tar.gz, and fixed lombok version . I retest this bug https://github.com/eclipse/eclipse.jdt.ls/issues/2591 and the issue persists

The jdtl process command

/Users/van/soft/jdk-17.0.6.jdk/Contents/Home/bin/java
-Declipse.application=org.eclipse.jdt.ls.core.id1
-Dosgi.bundles.defaultStartLevel=4
-Declipse.product=org.eclipse.jdt.ls.core.product
-Dlog.protocol=true -Dlog.level=ALL
-javaagent:/Users/van/Desktop/lombok.jar
-XX:+UseParallelGC
-XX:GCTimeRatio=4
-XX:AdaptiveSizePolicyWeight=90
-Dsun.zip.disableMemoryMapping=true
-Xmx2G
-Xms100m
-jar /Users/van/.emacs.d/.local/etc/lsp/eclipse.jdt.ls/plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar
-configuration /Users/van/.emacs.d/.local/etc/lsp/eclipse.jdt.ls/config_mac
-data /Users/van/.emacs.d/.local/etc/java-workspace 
--add-modules=ALL-SYSTEM 
--add-opens java.base/java.util=ALL-UNNAMED 
--add-opens java.base/java.lang=ALL-UNNAMED

[rgrunber]

Do you have a sample project somewhere that could be used to reproduce this issue ?

[snjeza]

@vanniuner could you check lombok edge release ? See https://projectlombok.org/download-edge

[sincebyte]

@vanniuner could you check lombok edge release ? See https://projectlombok.org/download-edge

1.18.26 this works well but this one can not startup jdt. https://projectlombok.org/lombok-edge.jar

[sincebyte]

Do you have a sample project somewhere that could be used to reproduce this issue ?

@rgrunber Thanks for your helping. I accept the different maven sub module name, cause I'm been busy lately. I'll test it later when I have time, may be a few weeks later At that time,I'll sync the project's struct to you

[snjeza]

but this one can not startup jdt. https://projectlombok.org/lombok-edge.jar

I can't reproduce the issue. Could you show an error output?