<build> or <plugin> elements are not imported when a project imports a BOM with <scope>import</scope>, only <dependencyManagement> is imported.
Other elements only get inherited when a project uses another project as a parent. > Op 8 jan 2024, om 20:57 heeft Ceki Gulcu <c...@qos.ch.INVALID> het volgende > geschreven: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
