Hej Ceki, I also experience javadoc misbehaviour when JPMS/jigsaw is involved, and _I think_ it boils down when it tries to be "smart" when it comes to JPMS... See master of maven-resolver, as it was suffering with similar issues, and this change: https://github.com/apache/maven-resolver/commit/baac2975488adf630c02141b882d1459d8c66fae (that was a few releases ago, things may have changed around).
Try out this flag if you are on fairly new version: https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#legacymode HTH Tamas On Thu, Dec 28, 2023 at 7:04 PM Ceki Gulcu <c...@qos.ch.invalid> wrote: > > Hello all, > > Given the javadoc generation is an important part of software projects, > maybe someone would care to comment whether the behavior described below > is expected or not? > > In the meantime, happy new year to all, > > -- > Ceki Gülcü > > Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch > > On 12/23/2023 9:34 PM, Ceki Gulcu wrote: > > > > Hello, > > > > I would like to share what looks to me like an unexpected behavior of > > the javadoc plugin, more specifically when run as javadoc:aggregate. > > > > > > The SLF4J project uses the "Refining the BOM Pattern" variant as > > explained in Garret Wilson's "Improving the BOM Pattern" [1]. More > > specifically, the top level pom.xml is the BOM and project modules > > import ../parent/pom.xml. > > > > Source code is available at [2]. > > > > Also, version 2.1.0-alpha0-SNAPSHOT is a fully jigsaw modularized > project. > > > > When trying to create aggregated javadocs with the javadoc:aggreate > > command, the javadoc generation would fail with javadoc complaining > > about unnamed modules and other miscellaneous problems. The solution was > > to skip certain modules for which there was no need to generate javadocs > > to begin with. > > > > Surprisingly, adding <skippedModules> in parent/pom.xml of the > > javdoc-plugin configuration would have no effect. However, specifying > > -Dmaven.javadoc.skippedModules would work as expected. > > > > The advice commonly found on various forum about the placement of the > > javadoc plugin configuration pertain to <reporting> and/or <build> > > section. In my case, this advice looks irrelevant (see below). > > > > After a lot of head scratching, placing the javadoc-plugin configuration > > in the BOM, i.e. the top-level pom.xml, made the javadoc-plugin > > configuration have the desired effect. This is quite surprising as the > > configuration of other plugins have an effect when placed in > parent/pom.xml. > > > > To reproduce this behavior, you can check out the code of the SLF4J > > project from [2] and run "mvn javadoc:aggregate". (To observe a failure > > the javadoc-plugin configuration needs to commented out in top-level > > pom.xml and uncommented in parent/pom.xml before running "mvn > > javadoc:aggregate".) > > > > I am wondering whether the behavior of javadoc:aggregate described above > > is expected or actually a problem? > > > > Best regards, > > > > [1] > https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern > > [2] https://github.com/qos-ch/slf4j/tree/branch_2.1.x > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
