Hi Tamás, Thank you for your comments.
My question is more regarding the need to place a javadoc <plugin> element in the BOM file, i.e top level pom.xml, instead of parent/pom.xml. Once the javadoc related <plugin> element is in the BOM file, it works fine. However, given the BOM file is intended to be imported, I would prefer to keep it minimal and have it free of any <build> and <plugin> elements in order to not pollute importing projects. Is my concern warranted? -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 12/28/2023 7:17 PM, Tamás Cservenák wrote: > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
