Re: Unexpected behavior of the javadoc plugin?
Hej Ceki, Nils is right, all the elements of BOM are ignored but the depMgt. So what you "pollute" are those extra handfuls of bytes that consumers download, only to toss them away. So this is not a problem IMHO. Thanks T On Tue, Jan 9, 2024 at 12:34 AM Nils Breunese wrote: > or elements are not imported when a project imports a BOM > with import, only 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 het > volgende geschreven: > > > > Hi Tamás, > > > > Thank you for your comments. > > > > My question is more regarding the need to place a javadoc > > element in the BOM file, i.e top level pom.xml, instead of > parent/pom.xml. > > > > Once the javadoc related 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 and 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 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 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 and/or > >>>> 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 th
Re: Unexpected behavior of the javadoc plugin?
or elements are not imported when a project imports a BOM with import, only 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 het volgende > geschreven: > > Hi Tamás, > > Thank you for your comments. > > My question is more regarding the need to place a javadoc > element in the BOM file, i.e top level pom.xml, instead of parent/pom.xml. > > Once the javadoc related 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 and 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 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 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 and/or >>>> 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
Re: Unexpected behavior of the javadoc plugin?
Hi Tamás, Thank you for your comments. My question is more regarding the need to place a javadoc element in the BOM file, i.e top level pom.xml, instead of parent/pom.xml. Once the javadoc related 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 and 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 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 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 and/or >>> 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
Re: Unexpected behavior of the javadoc plugin?
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 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 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 and/or > > 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 > >
Re: Unexpected behavior of the javadoc plugin?
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 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 and/or > 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
Unexpected behavior of the javadoc plugin?
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 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 and/or 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 -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org