[jira] [Comment Edited] (MJAVADOC-569) javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when mixing Java modules and non-modules

["Gili (JIRA)" <ji...@apache.org>]

    [ 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)