You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #4559, the checker-qual JAR provides a module-info.java description to be used by the Java platform module system (JPMS). However, its use is currently limited to the compiled .jar artifact. When generating JavaDoc for a module-aware, third-party project that uses checkerframework's annotations, the javadoc tool issues the following warning:
javadoc: warning - The code being documented uses modules but the packages defined in https://checkerframework.org/releases/3.48.3/api/ are in the unnamed module.
The problem is that the documentation is generated in a non-modular context ("java 8 mode") because the build process depends on some gradle-magic to resolve cyclic dependencies between checker-qual (at least in its documentation) and the checker implementation.
To resolve this issue, it should suffice to build the JavaDoc with a module-aware language level as well. However, this would require refactoring the documentation (and maybe more?) to resolve the cyclic dependencies which cannot exist between modules.
The text was updated successfully, but these errors were encountered:
With #4559, the checker-qual JAR provides a
module-info.java
description to be used by the Java platform module system (JPMS). However, its use is currently limited to the compiled.jar
artifact. When generating JavaDoc for a module-aware, third-party project that uses checkerframework's annotations, thejavadoc
tool issues the following warning:The problem is that the documentation is generated in a non-modular context ("java 8 mode") because the build process depends on some gradle-magic to resolve cyclic dependencies between checker-qual (at least in its documentation) and the checker implementation.
To resolve this issue, it should suffice to build the JavaDoc with a module-aware language level as well. However, this would require refactoring the documentation (and maybe more?) to resolve the cyclic dependencies which cannot exist between modules.
The text was updated successfully, but these errors were encountered: