[
https://issues.apache.org/jira/browse/MJAVADOC-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16749899#comment-16749899
]
Gili commented on MJAVADOC-569:
-------------------------------
If you are unable to come up with an easy fix for this issue, consider what
[Jonathan
wrote|https://bugs.openjdk.java.net/browse/JDK-8212233?focusedCommentId=14235193&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14235193]
a while back:
{quote}With respect to this issue, my going-in assumption is that if the module
path, class path, automatic modules, etc have been set up for *javadoc in a way
that mirrors the equivalent configuration for javac*, then it must be possible
to set up links for API for the modules (and unnamed module) in a reasonably
obvious manner.
That may not be as detailed as you want to see at this point, but I hope it
does outline the constraints for the design for a resolution.
{quote}
In theory, we should be able to argue that the Javadoc tool should accept
module1 on the module-path, module2 on the classpath and things should just
work. After all, they work this way for javac. It might be worth a try.
> javadoc:aggregate fails when mixing Java modules and non-modules, and
> non-module depends on other non-module
> ------------------------------------------------------------------------------------------------------------
>
> 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
> Priority: Blocker
> Attachments: 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)
