Another case where m2e fails to import a Maven project correctly

[davidmichaelkarr]

I work with a bunch of Java SpringBoot services built using Maven.

Using Eclipse 2022-06.

Every once in a while I import a Maven project where someone has persisted the .project and .classpath files in git, and when I import it, it has brain damage. It often doesn't set the source directories property. In almost all of those cases, I simply move the "dot files" out of the way (rename them) and then reimport the project, and it's all fine.

Every once in a while I run into a project that m2e is consistently confused about, even though it builds fine from the command line. I'm dealing with one of those now. When I first imported it, without removing the dot files, it groked it was a Maven project, but not a Java project. I tried enabling natures and adding the Java nature, but that didn't seem to help very much. I finally just copied over the dot files with the same files from a different project that is working fine, renaming the project name in the .project file. This also "almost works". I'm now getting "cannot be resolved" errors for classes that are inside maven dependencies that even Eclipse is showing me are present.

For instance, the first compile error it shows is "BDDMockito cannot be resolved". In the source file, the import of "org.mockito.BDDMockito" has the red line underneath "org.mockito", so that means it can't find that package.

In the Project Explorer, in that project, I expanded the "Maven Dependencies" entry and scrolled through all of the dependencies until I found "mockito-core-3.3.3.jar", which is exactly the dependency that is specified in the pom.xml. I expanded that and verified that "org.mockito.BDDMockito" is certainly present in that dependency.

I've tried doing a "Maven Update". That doesn't fix it.

I checked the .metadata/.log file, and there wasn't anything significant.

[mickaelistria]

Every once in a while I import a Maven project where someone has persisted the .project and .classpath files in git, and when I import it, it has brain damage. It often doesn't set the source directories property. In almost all of those cases, I simply move the "dot files" out of the way (rename them) and then reimport the project, and it's all fine.

It seems like you .classpath is incorrect. Just fix it (you may use m2e to generate a fixed one) and commit a fixed version. There is no point in keeping incorrect files in the repository in a state that makes import more difficult.

About the rest, please open a bug with a minimal project that reproduce the issue.

[davidmichaelkarr]

I have closely examined the .classpath, and I see nothing wrong with it. In fact, I can provide it here. I don't see anything surprising in it.

And how exactly would I use m2e to generate a fixed one?

Concerning providing a minimal project that reproduces the issue, you make it seem like this is just a trivial thing to do. I have no idea what it is about this project that is making this happen. I have many other projects that are not displaying this symptom, and all of them are very similar. In the past, I have tried to effectively do a "bisect" process to reproduce symptoms like this, which in general takes quite a bit of time, and I never got anywhere.

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
	<classpathentry kind="src" output="target/classes" path="src/main/java">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry excluding="**" kind="src" output="target/classes" path="src/main/resources">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="target/test-classes" path="src/test/java">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry excluding="**" kind="src" output="target/test-classes" path="src/test/resources">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry excluding="**" kind="src" output="target/classes" path="opt/ajsc/etc/config">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="GROOVY_DSL_SUPPORT">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="target/classes" path="target/generated-sources/xjc/ifsad">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="target/classes" path="target/generated-sources/xjc/ccp">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="output" path="target/classes"/>
</classpath>

[mickaelistria]

I think the .classpath misses the attribute on src/test/java folder to declare it's a test folder. Without it, the test dependencies from the Maven container are invisible to it.