You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ceki Gulcu <ce...@qos.ch.INVALID> on 2024/01/08 19:57:40 UTC
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 <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 <ce...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unexpected behavior of the javadoc plugin?
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ni...@breun.nl> wrote:
> <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 <ce...@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 <ce...@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unexpected behavior of the javadoc plugin?
Posted by Nils Breunese <ni...@breun.nl>.
<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 <ce...@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 <ce...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org