In multi-module dev mode, the DevUtil compile fails for a sub-module although compile mojo compilation suceeds.

[scottkurz]

SYMPTOM

The problem, for a multi-module project, is a compilation error in the compile done after dev mode detects changes, BUT without a corresponding failure simply doing mvn compile. In other words, the compile done by compiler:compile is fine... the compile done by the IDE is fine... but ONLY the dev mode compile fails.

Symptom like:

C:\ydosppa\apps\JarVersionConflict\guide-maven-multimodules\finish\war3\src\main\java\io\openliberty\guides\multimodules\web\HeightsBean.java:50: error: cannot find symbol
        this.feet = io.openliberty.guides.multimodules.lib.Converter.getFeet3(cm);
                                                                    ^
  symbol:   method getFeet3(int)
  location: class Converter
C:\ydosppa\apps\JarVersionConflict\guide-maven-multimodules\finish\war3\src\main\java\io\openliberty\guides\multimodules\web\HeightsBean.java:61: error: cannot find symbol
        this.inches = io.openliberty.guides.multimodules.lib.Converter.getInches3(cm);
                                                                      ^
  symbol:   method getInches3(int)
  location: class Converter
2 errors

though again mvn compile is fine.

RECREATE CONDITIONS

As mentioned below, it might only be a problem when there is a common parent shared by multiple sub modules in the reactor build.

Also the issue likely only becomes a true problem when there is a different version of a dependency used across different submodules. Otherwise, having extra entries on a sub-module's classpath isn't necessarily going to matter.

However, say we have WAR1 and WAR2 each depending on XYZ JAR V1 and XYZ JAR V2. This is generally fine to do with the classloader structure in Liberty. But the respective modules must only be compiled against the right V1 vs. V2 JAR (if there are compile-time diffs).

CODE TO LOOK AT

Looking at this in the debugger, I can see a likely problem in the code in DevMojoUtil.updateChildProjectArtifactPaths(File, List<String>, List<String>), at line 758 in which we loop through the children of the parent POM.
We loop through this sequence, which I'll annotate an excerpt of with comments:

https://github.com/OpenLiberty/ci.maven/blob/liberty-maven-3.10/liberty-maven-plugin/src/main/java/io/openliberty/tools/maven/server/DevMojo.java#L778

             // Get the submodule artifacts
             compileArtifacts = projectModule.getCompileArtifacts();
             ...

             // Here 'compileClasspathElements' is passed in from the method caller; it's a collection that initially has the classpath elems of the PARENT pom, but we add each child to it.
             compileClasspathElements.addAll(project.getCompileClasspathElements());
             ...

             // Now, to this reference to the child's compile artifacts we add the full parent set, even though this might be filled with entries coming from other children
             compileArtifacts.addAll(compileClasspathElements);

RECREATE

See instructions at: https://github.com/scottkurz/lmp1777-recreate