[MCOMPILER-317] Plugin generates wrong modulepath (dependencies listed in wrong order)

[jira-importer]

Gili opened MCOMPILER-317 and commented

Testcase: https://github.com/cowwoc/maven-java9-class-shadowing

If a project contains dependencies with the same module name (which is valid according to https://stackoverflow.com/a/46573805/14731) then maven-compile-plugin invokes javac with a modulepath containing dependencies in an (apparently) arbitrary order. If I place the project in one directory, I get one order. If I place the project in another directory, I get another order. This is 100% reproducible across multiple runs, across different computers.

I suspect that somewhere deep inside the code someone is using HashMap which is leading to undefined iteration order depending on the path being used.

Expected behavior: dependencies should be listed in the same order as declared in pom.xml (see https://stackoverflow.com/a/793193/14731)

Actual behavior: regardless of whether I list ExtensionPresent before or after MyLibrary, the wrong order gets passed to javac.

---

Affects: 3.7.0

Issue Links:

• MNG-6357 Dependency order should be nearest first

2 votes, 4 watchers

[jira-importer]

Robert Scholte commented

So in general the order of modules doesn't matter as long as they are unique. But this might be an interesting case. This must be fix in plexus-java. And it is indeed using a HashMap in the assumption that the overhead of a LinkedHashMap wasn't required.

[jira-importer]

Gili commented

Robert Scholte This is excellent news :)

I filed https://github.com/codehaus-plexus/plexus-languages/issues/4.

1. Will fixing this also fix https://github.com/mojohaus/exec-maven-plugin/issues/91 or is that a different issue?
2. How quickly do you think you could roll out a fix across both plugins?

Thank you.

[jira-importer]

Robert Scholte commented

Exec-maven-plugin is not using plexus-java. IIRC modulepath is exactly the same as classpath, it's just a naming thing ( <arg>--module-path</arg><classpath/> looks weird, right? ) So I don't understand that issue. For Plexus-Java it is a different story. I have to dive into this duplicate stuff. Simply allowing multiple modules with the same name on the modulepath comes with new issues, because the requires-statements are also read their module descriptors in order to decide where dependencies belong. Maybe it is better to adopt the mechanism that the first wins, now it is likely to be the last one.

[jira-importer]

Gili commented

Robert Scholte To clarify, it's not that the modulepath contains duplicate entries. It's that entries having different filenames/paths export the same module name.

My understanding is that modulepath is supposed to list these entries but then dependency resolution adopts a "first wins" approach.

[jira-importer]

Robert Scholte commented

Yes, I understand that. The lazy solutiuon would be to add both to the modulepath, but what to do with their requirements? If the first one requires modA and modB, the second modC and modD, do the all need to end up on the modulepath? I think it should be the first with modA and modB, and ignore the second module, just like the jdk would have done.

[jira-importer]

Gili commented

Robert Scholte If I understood you correctly, you need a list to hold the modulepath entries and a set to hold the requirements. The modulepath would contain both entries, but the set of requirements would only contain the entries from the first modulepath entry.

[jira-importer]

Gili commented

Robert Scholte I noticed that you fixed https://github.com/codehaus-plexus/plexus-languages/issues/4

Let me know once you have a SNAPSHOT release of MCOMPILER and I'll verify the fix on my end.

Also, I'd like to know how you wish to proceed with https://github.com/mojohaus/exec-maven-plugin/issues/91. Can you use the testcase I posted to investigate the cause there?

Thank you.

[jira-importer]

Robert Scholte commented

You can try plexus-java-0.9.6-SNAPSHOT from https://oss.sonatype.org/content/repositories/plexus-snapshots/ But it looks like there's more going on. Running with debug you'll see the classpath parameter (untouched) and it's order is already different to what I expect. There might be a deeper problem here and all plugins using the classpath will have this issue.

[jira-importer]

Gili commented

Robert Scholte It looks like the bug is in maven-project. See the comment I just posted: https://github.com/mojohaus/exec-maven-plugin/issues/91#issuecomment-353052306

[jira-importer]

Robert Scholte commented

That's kind of what I meant with "There might be a deeper problem here ..." I am really surprised if the order on the classpath is different to how we explain it to the world. Requires further investigation.