[ https://issues.apache.org/jira/browse/MJAVADOC-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753250#comment-16753250 ]
Gili edited comment on MJAVADOC-569 at 1/31/19 3:16 PM: -------------------------------------------------------- I got it working (export-to-testcase.zip) but I think it's worth having a follow-up discussion about how (and why) this works: * If the root project inherits from org.sonatype.oss:oss-parent:9 then the plugin logs this extra step "[DEBUG] Added Javadoc offline link: [http://nexus.sonatype.org/oss-repository-hosting.html/root/module1/apidocs] for the module: testcase:module1:jar:1.0-SNAPSHOT" * This causes the plugin to add "--add-modules module1" to the "options" file. * This leads to us getting a new error message: "package module1 is declared in module module1, which does not export it to the unnamed module". * To fix this, I had to add: {code:java} <additionalOptions> <option>--add-exports</option> <option>module1/module1=ALL-UNNAMED</option> </additionalOptions>{code} to module2's plugin configuration. I want to update the FAQ with more examples so I need your help in understand what is going on. Open questions: * Why aren't we always adding "--add-modules module1"? I think we should respect "export...to" in the presence of at least one module, even if no offline links are present. Is this a bug? * Are the above options the correct way to solve this problem? Meaning, are we forced to export the package into the unnamed module space? Couldn't we use "--patch-module" to convert module2 into a named module and in so doing (1) avoid having the user needing to declare <additionalOptional> (2) avoid exposing a package to modules that should not see it? was (Author: cowwoc): I got it working (export-to-testcase.zip) but I think it's worth having a follow-up discussion about how (and why) this works: * If the root project inherits from org.sonatype.oss:oss-parent:9 then the plugin logs this extra step "[DEBUG] Added Javadoc offline link: http://nexus.sonatype.org/oss-repository-hosting.html/root/module1/apidocs for the module: testcase:module1:jar:1.0-SNAPSHOT" * This causes the plugin to add "--add-modules module1" to the "options" file. * This leads to us getting a new error message: "package module1 is declared in module module1, which does not export it to the unnamed module". * To fix this, I had to add: {code:java} <additionalOptions> <option>--add-exports</option> <option>module1/module1=ALL-UNNAMED</option> </additionalOptions>{code} to module2's plugin configuration. I want to update the FAQ with more examples so I need your help in understand what is going on. Open questions: * Why aren't we always adding "--add-modules module1"? I think we should respect "export...to" in the presence of at least one module, even if no offline links are present. Is this a bug? * Are the above options the correct way to solve this problem? Meaning, are we forced to export the package into the unnamed module space? Couldn't we use "--patch-module" to convert module2 into a named module and in so doing (1) avoid having the user needing to declare <additionalOptional> (2) avoid exposing a package to modules that should not see it? > javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when > mixing Java modules and non-modules > ----------------------------------------------------------------------------------------------------------------- > > Key: MJAVADOC-569 > URL: https://issues.apache.org/jira/browse/MJAVADOC-569 > Project: Maven Javadoc Plugin > Issue Type: Bug > Environment: maven-javadoc-plugin 3.1.0-SNAPSHOT > Java 12-ea+28 > Reporter: Gili > Assignee: Robert Scholte > Priority: Blocker > Attachments: export-to-testcase.zip, testcase.zip > > > # Unpack testcase > # Run {{mvn clean package javadoc:aggregate -e}} > # {{javadoc:aggregate}} will fail with various errors like "(package > org.w3c.dom is declared in module java.xml, but module module2 does not read > it)" > Note that module 2 isn't really a Java Module but we are treating it as such > for the purposes of aggregating Javadoc across modularized and > non-modularized code. Module 2 has no way of declaring its intention of > reading the aforementioned package because it does not have a > {{module-info.java}} file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)