[MJAVADOC-682] Reactor builds fail when multiple modules with same groupId:artifactId, but different versions

[jira-importer]

AO Industries, Inc. opened MJAVADOC-682 and commented

In versions 3.1.0 through 3.6.2, when a reactor build has multiple projects with the same groupId and artifactId, even when different versions, the javadoc fails with:

Exit code: 1 - error: module not found: com.aoindustries.example

Plugin 3.0.1 works.

We have created a minimal example project that demonstrates this bug:

https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name

 

— Copy from demo project README.md —

To Reproduce:

1. Clone this project: git clone [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]
2. Change to project directory: cd maven-javadoc-plugin-failing-multiple-projects-same-name
3. Perform build to see error in jar goal: mvn verify
4. Also fails with javadoc goal: mvn clean compile javadoc:javadoc

Notes:

• Can build individual modules directly, such as (cd module-1 && mvn verify)
• Reverting to maven-javadoc-plugin version 3.0.1 makes it work
• Changing the groupId or artifactId in either module-1 or module-2 makes it work.
• Changing module names, package names, or class names in modules has no effect.
• We believe this to be distinct from Issue #673

---

Affects: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 3.5.0, 3.6.0, 3.6.2

Remote Links:

• GitHub Pull Request #253
  

[jira-importer]

Michael Osipov commented

That's an interesting case. I wonder whether this should work at all in Maven. Robert Scholte, what is your opinion on this?

[jira-importer]

Robert Scholte commented

I've once asked on the mailinglist if there's a usecase for having the same groupId+artifactId in the same reactor, because with Maven4 it is possible to remove versions for reactor dependencies, but in such case Maven would break.
So better start with answering the reasoning behind having 2 different version of the same groupId+artifactId within the same reactor.

[jira-importer]

AO Industries, Inc. commented

Multiple projects of the same groupId:artifactId, but with different versions, are an important part of our workflow.  We support multiple branches of many of our projects, and we have all projects in a giant Git submodule + Maven module hierarchy (including open-source components, corporate private internal projects, and client projects).  This allows us to perform aggregate tasks across all 984 projects at once, such as testing, analyzing dependencies, auditing ossindex vulnerabilities, deploying, publishing to Tomcats, ...

We've been using this capability heavily since our move to Maven five years ago.  It has served us very well.  The only known issue (prior to this bug) has been "mvn --resume-from ..." always resumes from the first matching project, which is fine since it is not a common situation.

Any loss of this capability would definitely increase our workload and decrease the utility of Maven.

 

And... thank you very much for your attention.

• Dan

[jira-importer]

AO Industries, Inc. commented

We have tested version 3.3.1 and confirm this issue remains.

 

We do observe one difference, however.  When doing mvn clean && mvn verify, we get a new error:

[ERROR] Creating an aggregated report for both named and unnamed modules is not possible.
[ERROR] Ensure that every module has a module descriptor or is a jar with a MANIFEST.MF containing an Automatic-Module-Name.
[ERROR] Fix the following projects:
[ERROR]  - com.aoindustries:ao-maven-javadoc-plugin-failing-multiple-projects-same-name-module

 

Whereas, if we do mvn clean && mvn compile && mvn verify, we see the same error as before:

[ERROR] Exit code: 1 - error: module not found: com.aoindustries.example
[ERROR] 
[ERROR] Command line was: /usr/lib/jvm/java-11-openjdk-amd64/bin/javadoc @options @packages @argfile
[ERROR] 
[ERROR] Refer to the generated Javadoc files in '/home/…/module-1/target/apidocs' dir.

Thank you,

• Dan

[jira-importer]

AO Industries, Inc. commented

We have tested version 3.3.2 and confirm this issue remains.

[jira-importer]

AO Industries, Inc. commented

We have tested version 3.4.0 and confirm this issue remains.

[jira-importer]

AO Industries, Inc. commented

We have tested version 3.4.1 and confirm this issue remains.

[jira-importer]

Michael Osipov commented

What is the first broken version? Did you try to bisect?

[jira-importer]

AO Industries, Inc. commented

3.1.0 was first version with this issue.  Version 3.0.1 is OK.

 

Looking for "bisect", I find a description: https://nurkiewicz.com/2014/03/automated-bug-finding-with-git-bisect.html

 

I find 85 commits between version 3.0.1 and 3.1.0.  Should I build each commit and see which is the first to fail?
maven-javadoc-plugin-3.0.1...maven-javadoc-plugin-3.1.0

[jira-importer]

Michael Osipov commented

Yes and not. "git bisect" will guide you with a binary search through those commits. You need to build and classify every commit Git offers you. Then you'll find it. I guess it will take around an hour or so.

[jira-importer]

AO Industries, Inc. commented

We have tested version 3.6.0 and confirm this issue remains.

[jira-importer]

Robert Scholte commented

The JavadocModule uses GA as key, seems like you want GAV here: https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/JavadocModule.java#L34

[jira-importer]

AO Industries, Inc. commented

We have tested version 3.6.2 and confirm this issue remains.

[jira-importer]

Michael Osipov commented

I have now created a PR which does a simple search and replace by adding the version to the formula. It works for me with the supplied project. AO Industries, Inc. , now you need to fork my branch and integrate your test case into an IT. As soon as this is complete and other committers consider this as a reasonable solution I will merge it.

[jira-importer]

AO Industries, Inc. commented

Michael Osipov Thank you and understood.  I have forked the repository, including all branches, and have MJAVADOC-682 checked-out.  I will create integration test in the morning.