Why do I get "Project 'captchams' is missing required Java project: 'idp-shutdown-jersey'" when it has no required projects?

[davidmichaelkarr]

I'm using the new Eclipse 4.33.0 distro, which includes 2.6.2.20240828-1954 of m2e.

I'm seeing a new problem that appears to be associated with m2e. I've imported an existing project from my git repos, which I had earlier imported in my 4.32 distribution.

The project has a red bang on it, with the one error saying this:

Project 'captchams' is missing required Java project: 'idp-shutdown-jersey'

This project definitely depends on the "idp-shutdown-jersey" artifact, as it's a transient dependency of one of our dependencies. However, I have no idea why it thinks it depends on the "idp-shutdown-jersey" PROJECT. I have "Workspace resolution" disabled in "captchams". I do have an Eclipse project for "idp-shutdown-jersey", but I want "captchams" to depend on the Maven artifact, not the Eclipse project.

When I inspect the "Java Build Path" for "captchams" and the "Projects" tab, it lists the "ModulePath" and "Classpath" headers, but there are no projects listed there.

If it isn't obvious, this application builds perfectly fine from the "mvn" command line.

I also have other similarly constructed applications that are failing with almost exactly the same error, except for different projects being "required". I did not see these errors in 2024-06 or before.

[davidmichaelkarr]

I just looked in the eclipse log, and I saw some obvious issues related to m2e:

!ENTRY org.eclipse.m2e.logback.appender 2 0 2024-09-14 08:38:09.122
!MESSAGE could not create Dir using bundle from url bundleresource://332.fwk8625653:15/. skipping.
!STACK 0
java.lang.ClassNotFoundException: org.eclipse.core.runtime.FileLocator
    at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:225)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:210)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:205)
    at org.reflections.vfs.Vfs$DefaultUrlTypes$6.createDir(Vfs.java:274)
    at org.reflections.vfs.Vfs.fromURL(Vfs.java:98)
    at org.reflections.vfs.Vfs.fromURL(Vfs.java:90)
    at org.reflections.Reflections.scan(Reflections.java:236)
    at org.reflections.Reflections.scan(Reflections.java:203)
    at org.reflections.Reflections.<init>(Reflections.java:128)
    at org.reflections.Reflections.<init>(Reflections.java:169)
    at org.reflections.Reflections.<init>(Reflections.java:142)
    at com.github.kongchen.swagger.docgen.reader.JaxrsReader.scanClasspathForTags(JaxrsReader.java:201)
    at com.github.kongchen.swagger.docgen.reader.JaxrsReader.read(JaxrsReader.java:102)
    at com.github.kongchen.swagger.docgen.reader.JaxrsReader.read(JaxrsReader.java:85)
    at com.github.kongchen.swagger.docgen.reader.JaxrsReader.read(JaxrsReader.java:75)
    at com.github.kongchen.swagger.docgen.AbstractDocumentSource.loadDocuments(AbstractDocumentSource.java:104)
    at com.github.kongchen.swagger.docgen.mavenplugin.ApiDocumentMojo.execute(ApiDocumentMojo.java:96)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:402)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$2(MavenExecutionContext.java:355)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:458)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:339)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:354)
    at org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
    at org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:159)
    at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
    at org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:139)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:458)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:292)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:458)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:339)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:278)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1077)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
!ENTRY org.eclipse.m2e.logback.appender 2 0 2024-09-14 08:38:09.122
!MESSAGE could not create Dir using commons_vfs2 from url bundleresource://332.fwk8625653:15/. skipping.
!STACK 0
java.lang.NoClassDefFoundError: org/apache/commons/vfs2/VFS
    at org.reflections.vfs.Vfs$DefaultUrlTypes$7.matches(Vfs.java:281)
    at org.reflections.vfs.Vfs.fromURL(Vfs.java:97)
    at org.reflections.vfs.Vfs.fromURL(Vfs.java:90)
    at org.reflections.Reflections.scan(Reflections.java:236)
    at org.reflections.Reflections.scan(Reflections.java:203)
    at org.reflections.Reflections.<init>(Reflections.java:128)
    at org.reflections.Reflections.<init>(Reflections.java:169)
    at org.reflections.Reflections.<init>(Reflections.java:142)
    at com.github.kongchen.swagger.docgen.reader.JaxrsReader.scanClasspathForTags(JaxrsReader.java:201)
    at com.github.kongchen.swagger.docgen.reader.JaxrsReader.read(JaxrsReader.java:102)
    at com.github.kongchen.swagger.docgen.reader.JaxrsReader.read(JaxrsReader.java:85)
    at com.github.kongchen.swagger.docgen.reader.JaxrsReader.read(JaxrsReader.java:75)
    at com.github.kongchen.swagger.docgen.AbstractDocumentSource.loadDocuments(AbstractDocumentSource.java:104)
    at com.github.kongchen.swagger.docgen.mavenplugin.ApiDocumentMojo.execute(ApiDocumentMojo.java:96)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:402)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$2(MavenExecutionContext.java:355)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:458)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:339)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:354)
    at org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
    at org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:159)
    at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
    at org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:139)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:458)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:292)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:458)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:339)
    at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:278)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1077)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.vfs2.VFS
    ... 48 more

[laeubi]

I just looked in the eclipse log, and I saw some obvious issues related to m2e:

This is caused by com.github.kongchen.swagger.docgen.reader.JaxrsReader and not by m2e.

When I inspect the "Java Build Path" for "captchams" and the "Projects" tab, it lists the "ModulePath" and "Classpath" headers, but there are no projects listed there.

Have you checked the .classpath file?

[davidmichaelkarr]

Ok, so I can see that if I comment out the reference to the "swagger-maven-plugin", which includes that class, and then reimport, it does get past that point. However, this is exactly the same repository that I previously imported with 2024-06, which does not have that error when I import it.

However, even in 2024-06, importing this repository doesn't result in a .classpath file being created at all. There is no error saying it was unable to do it, it just finishes, and there is no .classpath file. In fact, I see this same symptom in all of our SpringBoot Maven repositories, for the last couple of releases. There was a time perhaps a year or so ago, when it was still able to generated a .classpath file on import, but not anymore. I've been forced to simply keep a copy of the old .classpath file and I copy it into each project and then make changes from the project properties dialog for any variations (generated source directories, for instance).

However, I tried some experiments today, and I find that if I change my pom.xml to not specify a parent pom, it is at least able to generate a .classpath file, although it needs modifications after the fact. I suppose I could import the project with the parent pom commented out, then comment it back in and fix my project properties. It's all still a big hack, however.

I also tried iterating on the parent pom, by manually changing the pom file in my local maven repo. I commented out almost all of it, only leaving the groupId, artifactId, modelVersion, version, and packaging properties. That didn't make a difference. If my repository pom specifies the parent pom, it doesn't generate the .classpath file. If I comment out the parent-pom reference, it does.

This is essentially two different problems, although they might be related.

[laeubi]

It is quite hard to guess from the description, so probably you can share an example that reproduce the problem?

[davidmichaelkarr]

I have tried many times to construct an example that reproduces this that I can package up and send. I can repeat this easily with almost every application in our domain that I've tried it with (I say "almost" because I doubt I've tried every application in our domain), but I've never been able to reproduce this with a trivial example.

I've tried other experiments, like creating a new empty workspace and importing the application, that has the same result.

I've also tried a fresh installation of Eclipse, without any of the plugins I typically install, with a new empty workspace, and that still failed to produce a .classpath file, but it did have a slightly different result. In my normal Eclipse distribution, the import results in a .project file that has both the Maven and Java natures, but with no .classpath file. In the "clean" installation with no plugins, it also doesn't produce a .classpath file, but it also doesn't have a Java nature in the .project file.

It would really be helpful if there were some additional diagnostics we could enable.