You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Volkan Yazıcı <vo...@yazi.ci> on 2022/05/19 06:38:53 UTC
Consuming our own BOM
Even though we provide a BOM module (`log4j-bom`), we don't consume it
ourselves. Hence occasionally we end up publishing artifacts not included
in the BOM. Consuming our own BOM decreases the chances of missing out
artifacts in BOM, though doesn't totally eliminate the chances of that
happening.
When I read how Maven advises to structure the BOM module
<https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>,
I understand what needs to be in the case of Log4j is the following:
/pom.xml (`log4j-bom` module)
/log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
/log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
Though what we have in reality is the following:
/log4j-bom/pom.xml (`log4j-bom` module)
/pom.xml (`log4j` module parented by `logging-parent`)
/log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
Ideally we should follow the Maven-advised approach and consume from our
BOM parented by `logging-parent`.
What do you think? Is my interpretation of the Maven-advised approach
correct?
Re: Consuming our own BOM
Posted by Matt Sicker <bo...@gmail.com>.
And it’s much simpler than moving the BOM around. Very nice!
—
Matt Sicker
> On May 30, 2022, at 09:44, Apache <ra...@dslextreme.com> wrote:
>
> It is implemented on master.
>
> Ralph
>
>> On May 30, 2022, at 2:27 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>
>> Mind somebody sharing the last state? Is it implemented, if so how and on
>> which branch(es)? Is it reverted? If so, totally or partially?
>>
>>> On Sun, May 29, 2022 at 9:53 AM Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>> That is OK. I have reverted your commit and am testing the build for a
>>> second time doing it the correct way.
>>>
>>> Ralph
>>>
>>>>>> On May 28, 2022, at 9:14 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> It worked, but I had to specify where the parent pom was in the
>>> submodules. Are you saying I could get the same effect by importing the bom
>>> in the parent pom? If so, that certainly seems easier.
>>>>
>>>> —
>>>> Matt Sicker
>>>>
>>>>> On May 28, 2022, at 18:15, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>>>
>>>>> Why is this necessary? I would think having the parent import the
>>> bom/pom.xml should be enough.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On May 27, 2022, at 6:18 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> To avoid rearranging all the directories, I'm moving the parent pom to
>>>>>> its own directory, moving the bom pom to the root, and updating the
>>>>>> rest of the poms to know where the old parent pom now is.
>>>>>>
>>>>>>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> Agreed. I added the BOM POM later on and didn’t know of any
>>> established patterns for modules as BOMs weren’t used extensively quite yet
>>> at the time (and it was a Maven specific feature then, too; Spring ported
>>> the concept to Gradle later on, and now Gradle has a native concept of the
>>> same thing).
>>>>>>>
>>>>>>> —
>>>>>>> Matt Sicker
>>>>>>>
>>>>>>>> On May 19, 2022, at 10:33, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>>>>>
>>>>>>> Yes, that would make sense. I am sure this happened simply because
>>> the bom pom.xml was introduced way after the first releases.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Even though we provide a BOM module (`log4j-bom`), we don't consume it
>>>>>>>
>>>>>>> ourselves. Hence occasionally we end up publishing artifacts not
>>> included
>>>>>>>
>>>>>>> in the BOM. Consuming our own BOM decreases the chances of missing out
>>>>>>>
>>>>>>> artifacts in BOM, though doesn't totally eliminate the chances of that
>>>>>>>
>>>>>>> happening.
>>>>>>>
>>>>>>>
>>>>>>> When I read how Maven advises to structure the BOM module
>>>>>>>
>>>>>>> <
>>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
>>>> ,
>>>>>>>
>>>>>>> I understand what needs to be in the case of Log4j is the following:
>>>>>>>
>>>>>>>
>>>>>>> /pom.xml (`log4j-bom` module)
>>>>>>>
>>>>>>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>>>>>>>
>>>>>>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by
>>> `log4j`)
>>>>>>>
>>>>>>>
>>>>>>> Though what we have in reality is the following:
>>>>>>>
>>>>>>>
>>>>>>> /log4j-bom/pom.xml (`log4j-bom` module)
>>>>>>>
>>>>>>> /pom.xml (`log4j` module parented by `logging-parent`)
>>>>>>>
>>>>>>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>>>>>>
>>>>>>>
>>>>>>> Ideally we should follow the Maven-advised approach and consume from
>>> our
>>>>>>>
>>>>>>> BOM parented by `logging-parent`.
>>>>>>>
>>>>>>>
>>>>>>> What do you think? Is my interpretation of the Maven-advised approach
>>>>>>>
>>>>>>> correct?
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>
Re: Consuming our own BOM
Posted by Ralph Goers <ra...@dslextreme.com>.
Because I am close to cutting the release and only want real bug fixes at this point.
Ralph
> On Jun 1, 2022, at 11:55 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> Mind explaining why, please? (Assuming this is a relatively small fix as
> Matt stated.)
>
> On Wed, Jun 1, 2022 at 5:08 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Yes. I don’t want to do this for 2.18.0.
>>
>> Ralph
>>
>>> On Jun 1, 2022, at 3:14 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>>
>>> Was there a particular reason we skipped `release-2.x`?
>>>
>>> On Mon, May 30, 2022 at 4:44 PM Apache <ra...@dslextreme.com>
>> wrote:
>>>
>>>> It is implemented on master.
>>>>
>>>> Ralph
>>>>
>>>>> On May 30, 2022, at 2:27 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>>>>
>>>>> Mind somebody sharing the last state? Is it implemented, if so how and
>>>> on
>>>>> which branch(es)? Is it reverted? If so, totally or partially?
>>>>>
>>>>>> On Sun, May 29, 2022 at 9:53 AM Ralph Goers <
>> ralph.goers@dslextreme.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> That is OK. I have reverted your commit and am testing the build for a
>>>>>> second time doing it the correct way.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>>> On May 28, 2022, at 9:14 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> It worked, but I had to specify where the parent pom was in the
>>>>>> submodules. Are you saying I could get the same effect by importing
>> the
>>>> bom
>>>>>> in the parent pom? If so, that certainly seems easier.
>>>>>>>
>>>>>>> —
>>>>>>> Matt Sicker
>>>>>>>
>>>>>>>> On May 28, 2022, at 18:15, Ralph Goers <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Why is this necessary? I would think having the parent import the
>>>>>> bom/pom.xml should be enough.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On May 27, 2022, at 6:18 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> To avoid rearranging all the directories, I'm moving the parent pom
>>>> to
>>>>>>>>> its own directory, moving the bom pom to the root, and updating the
>>>>>>>>> rest of the poms to know where the old parent pom now is.
>>>>>>>>>
>>>>>>>>>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Agreed. I added the BOM POM later on and didn’t know of any
>>>>>> established patterns for modules as BOMs weren’t used extensively
>> quite
>>>> yet
>>>>>> at the time (and it was a Maven specific feature then, too; Spring
>>>> ported
>>>>>> the concept to Gradle later on, and now Gradle has a native concept of
>>>> the
>>>>>> same thing).
>>>>>>>>>>
>>>>>>>>>> —
>>>>>>>>>> Matt Sicker
>>>>>>>>>>
>>>>>>>>>>> On May 19, 2022, at 10:33, Ralph Goers <
>> ralph.goers@dslextreme.com
>>>>>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Yes, that would make sense. I am sure this happened simply
>> because
>>>>>> the bom pom.xml was introduced way after the first releases.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Even though we provide a BOM module (`log4j-bom`), we don't
>> consume
>>>> it
>>>>>>>>>>
>>>>>>>>>> ourselves. Hence occasionally we end up publishing artifacts not
>>>>>> included
>>>>>>>>>>
>>>>>>>>>> in the BOM. Consuming our own BOM decreases the chances of missing
>>>> out
>>>>>>>>>>
>>>>>>>>>> artifacts in BOM, though doesn't totally eliminate the chances of
>>>> that
>>>>>>>>>>
>>>>>>>>>> happening.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When I read how Maven advises to structure the BOM module
>>>>>>>>>>
>>>>>>>>>> <
>>>>>>
>>>>
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
>>>>>>> ,
>>>>>>>>>>
>>>>>>>>>> I understand what needs to be in the case of Log4j is the
>> following:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /pom.xml (`log4j-bom` module)
>>>>>>>>>>
>>>>>>>>>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>>>>>>>>>>
>>>>>>>>>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by
>>>>>> `log4j`)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Though what we have in reality is the following:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /log4j-bom/pom.xml (`log4j-bom` module)
>>>>>>>>>>
>>>>>>>>>> /pom.xml (`log4j` module parented by `logging-parent`)
>>>>>>>>>>
>>>>>>>>>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ideally we should follow the Maven-advised approach and consume
>> from
>>>>>> our
>>>>>>>>>>
>>>>>>>>>> BOM parented by `logging-parent`.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What do you think? Is my interpretation of the Maven-advised
>>>> approach
>>>>>>>>>>
>>>>>>>>>> correct?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: Consuming our own BOM
Posted by Volkan Yazıcı <vo...@yazi.ci>.
Mind explaining why, please? (Assuming this is a relatively small fix as
Matt stated.)
On Wed, Jun 1, 2022 at 5:08 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> Yes. I don’t want to do this for 2.18.0.
>
> Ralph
>
> > On Jun 1, 2022, at 3:14 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> >
> > Was there a particular reason we skipped `release-2.x`?
> >
> > On Mon, May 30, 2022 at 4:44 PM Apache <ra...@dslextreme.com>
> wrote:
> >
> >> It is implemented on master.
> >>
> >> Ralph
> >>
> >>> On May 30, 2022, at 2:27 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> >>>
> >>> Mind somebody sharing the last state? Is it implemented, if so how and
> >> on
> >>> which branch(es)? Is it reverted? If so, totally or partially?
> >>>
> >>>> On Sun, May 29, 2022 at 9:53 AM Ralph Goers <
> ralph.goers@dslextreme.com
> >>>
> >>>> wrote:
> >>>>
> >>>> That is OK. I have reverted your commit and am testing the build for a
> >>>> second time doing it the correct way.
> >>>>
> >>>> Ralph
> >>>>
> >>>>>> On May 28, 2022, at 9:14 PM, Matt Sicker <bo...@gmail.com> wrote:
> >>>>>
> >>>>> It worked, but I had to specify where the parent pom was in the
> >>>> submodules. Are you saying I could get the same effect by importing
> the
> >> bom
> >>>> in the parent pom? If so, that certainly seems easier.
> >>>>>
> >>>>> —
> >>>>> Matt Sicker
> >>>>>
> >>>>>> On May 28, 2022, at 18:15, Ralph Goers <ra...@dslextreme.com>
> >>>> wrote:
> >>>>>>
> >>>>>> Why is this necessary? I would think having the parent import the
> >>>> bom/pom.xml should be enough.
> >>>>>>
> >>>>>> Ralph
> >>>>>>
> >>>>>>> On May 27, 2022, at 6:18 PM, Matt Sicker <bo...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> To avoid rearranging all the directories, I'm moving the parent pom
> >> to
> >>>>>>> its own directory, moving the bom pom to the root, and updating the
> >>>>>>> rest of the poms to know where the old parent pom now is.
> >>>>>>>
> >>>>>>>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com>
> >> wrote:
> >>>>>>>>
> >>>>>>>> Agreed. I added the BOM POM later on and didn’t know of any
> >>>> established patterns for modules as BOMs weren’t used extensively
> quite
> >> yet
> >>>> at the time (and it was a Maven specific feature then, too; Spring
> >> ported
> >>>> the concept to Gradle later on, and now Gradle has a native concept of
> >> the
> >>>> same thing).
> >>>>>>>>
> >>>>>>>> —
> >>>>>>>> Matt Sicker
> >>>>>>>>
> >>>>>>>>> On May 19, 2022, at 10:33, Ralph Goers <
> ralph.goers@dslextreme.com
> >>>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>> Yes, that would make sense. I am sure this happened simply
> because
> >>>> the bom pom.xml was introduced way after the first releases.
> >>>>>>>>
> >>>>>>>> Ralph
> >>>>>>>>
> >>>>>>>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci>
> >> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Even though we provide a BOM module (`log4j-bom`), we don't
> consume
> >> it
> >>>>>>>>
> >>>>>>>> ourselves. Hence occasionally we end up publishing artifacts not
> >>>> included
> >>>>>>>>
> >>>>>>>> in the BOM. Consuming our own BOM decreases the chances of missing
> >> out
> >>>>>>>>
> >>>>>>>> artifacts in BOM, though doesn't totally eliminate the chances of
> >> that
> >>>>>>>>
> >>>>>>>> happening.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> When I read how Maven advises to structure the BOM module
> >>>>>>>>
> >>>>>>>> <
> >>>>
> >>
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
> >>>>> ,
> >>>>>>>>
> >>>>>>>> I understand what needs to be in the case of Log4j is the
> following:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> /pom.xml (`log4j-bom` module)
> >>>>>>>>
> >>>>>>>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
> >>>>>>>>
> >>>>>>>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by
> >>>> `log4j`)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Though what we have in reality is the following:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> /log4j-bom/pom.xml (`log4j-bom` module)
> >>>>>>>>
> >>>>>>>> /pom.xml (`log4j` module parented by `logging-parent`)
> >>>>>>>>
> >>>>>>>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Ideally we should follow the Maven-advised approach and consume
> from
> >>>> our
> >>>>>>>>
> >>>>>>>> BOM parented by `logging-parent`.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> What do you think? Is my interpretation of the Maven-advised
> >> approach
> >>>>>>>>
> >>>>>>>> correct?
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Consuming our own BOM
Posted by Ralph Goers <ra...@dslextreme.com>.
Yes. I don’t want to do this for 2.18.0.
Ralph
> On Jun 1, 2022, at 3:14 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> Was there a particular reason we skipped `release-2.x`?
>
> On Mon, May 30, 2022 at 4:44 PM Apache <ra...@dslextreme.com> wrote:
>
>> It is implemented on master.
>>
>> Ralph
>>
>>> On May 30, 2022, at 2:27 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>>
>>> Mind somebody sharing the last state? Is it implemented, if so how and
>> on
>>> which branch(es)? Is it reverted? If so, totally or partially?
>>>
>>>> On Sun, May 29, 2022 at 9:53 AM Ralph Goers <ralph.goers@dslextreme.com
>>>
>>>> wrote:
>>>>
>>>> That is OK. I have reverted your commit and am testing the build for a
>>>> second time doing it the correct way.
>>>>
>>>> Ralph
>>>>
>>>>>> On May 28, 2022, at 9:14 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> It worked, but I had to specify where the parent pom was in the
>>>> submodules. Are you saying I could get the same effect by importing the
>> bom
>>>> in the parent pom? If so, that certainly seems easier.
>>>>>
>>>>> —
>>>>> Matt Sicker
>>>>>
>>>>>> On May 28, 2022, at 18:15, Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>>>
>>>>>> Why is this necessary? I would think having the parent import the
>>>> bom/pom.xml should be enough.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On May 27, 2022, at 6:18 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> To avoid rearranging all the directories, I'm moving the parent pom
>> to
>>>>>>> its own directory, moving the bom pom to the root, and updating the
>>>>>>> rest of the poms to know where the old parent pom now is.
>>>>>>>
>>>>>>>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com>
>> wrote:
>>>>>>>>
>>>>>>>> Agreed. I added the BOM POM later on and didn’t know of any
>>>> established patterns for modules as BOMs weren’t used extensively quite
>> yet
>>>> at the time (and it was a Maven specific feature then, too; Spring
>> ported
>>>> the concept to Gradle later on, and now Gradle has a native concept of
>> the
>>>> same thing).
>>>>>>>>
>>>>>>>> —
>>>>>>>> Matt Sicker
>>>>>>>>
>>>>>>>>> On May 19, 2022, at 10:33, Ralph Goers <ralph.goers@dslextreme.com
>>>
>>>> wrote:
>>>>>>>>
>>>>>>>> Yes, that would make sense. I am sure this happened simply because
>>>> the bom pom.xml was introduced way after the first releases.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci>
>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Even though we provide a BOM module (`log4j-bom`), we don't consume
>> it
>>>>>>>>
>>>>>>>> ourselves. Hence occasionally we end up publishing artifacts not
>>>> included
>>>>>>>>
>>>>>>>> in the BOM. Consuming our own BOM decreases the chances of missing
>> out
>>>>>>>>
>>>>>>>> artifacts in BOM, though doesn't totally eliminate the chances of
>> that
>>>>>>>>
>>>>>>>> happening.
>>>>>>>>
>>>>>>>>
>>>>>>>> When I read how Maven advises to structure the BOM module
>>>>>>>>
>>>>>>>> <
>>>>
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
>>>>> ,
>>>>>>>>
>>>>>>>> I understand what needs to be in the case of Log4j is the following:
>>>>>>>>
>>>>>>>>
>>>>>>>> /pom.xml (`log4j-bom` module)
>>>>>>>>
>>>>>>>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>>>>>>>>
>>>>>>>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by
>>>> `log4j`)
>>>>>>>>
>>>>>>>>
>>>>>>>> Though what we have in reality is the following:
>>>>>>>>
>>>>>>>>
>>>>>>>> /log4j-bom/pom.xml (`log4j-bom` module)
>>>>>>>>
>>>>>>>> /pom.xml (`log4j` module parented by `logging-parent`)
>>>>>>>>
>>>>>>>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>>>>>>>
>>>>>>>>
>>>>>>>> Ideally we should follow the Maven-advised approach and consume from
>>>> our
>>>>>>>>
>>>>>>>> BOM parented by `logging-parent`.
>>>>>>>>
>>>>>>>>
>>>>>>>> What do you think? Is my interpretation of the Maven-advised
>> approach
>>>>>>>>
>>>>>>>> correct?
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: Consuming our own BOM
Posted by Volkan Yazıcı <vo...@yazi.ci>.
Was there a particular reason we skipped `release-2.x`?
On Mon, May 30, 2022 at 4:44 PM Apache <ra...@dslextreme.com> wrote:
> It is implemented on master.
>
> Ralph
>
> > On May 30, 2022, at 2:27 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> >
> > Mind somebody sharing the last state? Is it implemented, if so how and
> on
> > which branch(es)? Is it reverted? If so, totally or partially?
> >
> >> On Sun, May 29, 2022 at 9:53 AM Ralph Goers <ralph.goers@dslextreme.com
> >
> >> wrote:
> >>
> >> That is OK. I have reverted your commit and am testing the build for a
> >> second time doing it the correct way.
> >>
> >> Ralph
> >>
> >>>> On May 28, 2022, at 9:14 PM, Matt Sicker <bo...@gmail.com> wrote:
> >>>
> >>> It worked, but I had to specify where the parent pom was in the
> >> submodules. Are you saying I could get the same effect by importing the
> bom
> >> in the parent pom? If so, that certainly seems easier.
> >>>
> >>> —
> >>> Matt Sicker
> >>>
> >>>> On May 28, 2022, at 18:15, Ralph Goers <ra...@dslextreme.com>
> >> wrote:
> >>>>
> >>>> Why is this necessary? I would think having the parent import the
> >> bom/pom.xml should be enough.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On May 27, 2022, at 6:18 PM, Matt Sicker <bo...@gmail.com> wrote:
> >>>>>
> >>>>> To avoid rearranging all the directories, I'm moving the parent pom
> to
> >>>>> its own directory, moving the bom pom to the root, and updating the
> >>>>> rest of the poms to know where the old parent pom now is.
> >>>>>
> >>>>>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> Agreed. I added the BOM POM later on and didn’t know of any
> >> established patterns for modules as BOMs weren’t used extensively quite
> yet
> >> at the time (and it was a Maven specific feature then, too; Spring
> ported
> >> the concept to Gradle later on, and now Gradle has a native concept of
> the
> >> same thing).
> >>>>>>
> >>>>>> —
> >>>>>> Matt Sicker
> >>>>>>
> >>>>>>> On May 19, 2022, at 10:33, Ralph Goers <ralph.goers@dslextreme.com
> >
> >> wrote:
> >>>>>>
> >>>>>> Yes, that would make sense. I am sure this happened simply because
> >> the bom pom.xml was introduced way after the first releases.
> >>>>>>
> >>>>>> Ralph
> >>>>>>
> >>>>>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci>
> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Even though we provide a BOM module (`log4j-bom`), we don't consume
> it
> >>>>>>
> >>>>>> ourselves. Hence occasionally we end up publishing artifacts not
> >> included
> >>>>>>
> >>>>>> in the BOM. Consuming our own BOM decreases the chances of missing
> out
> >>>>>>
> >>>>>> artifacts in BOM, though doesn't totally eliminate the chances of
> that
> >>>>>>
> >>>>>> happening.
> >>>>>>
> >>>>>>
> >>>>>> When I read how Maven advises to structure the BOM module
> >>>>>>
> >>>>>> <
> >>
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
> >>> ,
> >>>>>>
> >>>>>> I understand what needs to be in the case of Log4j is the following:
> >>>>>>
> >>>>>>
> >>>>>> /pom.xml (`log4j-bom` module)
> >>>>>>
> >>>>>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
> >>>>>>
> >>>>>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by
> >> `log4j`)
> >>>>>>
> >>>>>>
> >>>>>> Though what we have in reality is the following:
> >>>>>>
> >>>>>>
> >>>>>> /log4j-bom/pom.xml (`log4j-bom` module)
> >>>>>>
> >>>>>> /pom.xml (`log4j` module parented by `logging-parent`)
> >>>>>>
> >>>>>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
> >>>>>>
> >>>>>>
> >>>>>> Ideally we should follow the Maven-advised approach and consume from
> >> our
> >>>>>>
> >>>>>> BOM parented by `logging-parent`.
> >>>>>>
> >>>>>>
> >>>>>> What do you think? Is my interpretation of the Maven-advised
> approach
> >>>>>>
> >>>>>> correct?
> >>>>>>
> >>>>>>
> >>>>
> >>
> >>
>
>
Re: Consuming our own BOM
Posted by Apache <ra...@dslextreme.com>.
It is implemented on master.
Ralph
> On May 30, 2022, at 2:27 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> Mind somebody sharing the last state? Is it implemented, if so how and on
> which branch(es)? Is it reverted? If so, totally or partially?
>
>> On Sun, May 29, 2022 at 9:53 AM Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>> That is OK. I have reverted your commit and am testing the build for a
>> second time doing it the correct way.
>>
>> Ralph
>>
>>>> On May 28, 2022, at 9:14 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> It worked, but I had to specify where the parent pom was in the
>> submodules. Are you saying I could get the same effect by importing the bom
>> in the parent pom? If so, that certainly seems easier.
>>>
>>> —
>>> Matt Sicker
>>>
>>>> On May 28, 2022, at 18:15, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>>>
>>>> Why is this necessary? I would think having the parent import the
>> bom/pom.xml should be enough.
>>>>
>>>> Ralph
>>>>
>>>>> On May 27, 2022, at 6:18 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> To avoid rearranging all the directories, I'm moving the parent pom to
>>>>> its own directory, moving the bom pom to the root, and updating the
>>>>> rest of the poms to know where the old parent pom now is.
>>>>>
>>>>>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> Agreed. I added the BOM POM later on and didn’t know of any
>> established patterns for modules as BOMs weren’t used extensively quite yet
>> at the time (and it was a Maven specific feature then, too; Spring ported
>> the concept to Gradle later on, and now Gradle has a native concept of the
>> same thing).
>>>>>>
>>>>>> —
>>>>>> Matt Sicker
>>>>>>
>>>>>>> On May 19, 2022, at 10:33, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>>>>>
>>>>>> Yes, that would make sense. I am sure this happened simply because
>> the bom pom.xml was introduced way after the first releases.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>>>>>
>>>>>>
>>>>>> Even though we provide a BOM module (`log4j-bom`), we don't consume it
>>>>>>
>>>>>> ourselves. Hence occasionally we end up publishing artifacts not
>> included
>>>>>>
>>>>>> in the BOM. Consuming our own BOM decreases the chances of missing out
>>>>>>
>>>>>> artifacts in BOM, though doesn't totally eliminate the chances of that
>>>>>>
>>>>>> happening.
>>>>>>
>>>>>>
>>>>>> When I read how Maven advises to structure the BOM module
>>>>>>
>>>>>> <
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
>>> ,
>>>>>>
>>>>>> I understand what needs to be in the case of Log4j is the following:
>>>>>>
>>>>>>
>>>>>> /pom.xml (`log4j-bom` module)
>>>>>>
>>>>>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>>>>>>
>>>>>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by
>> `log4j`)
>>>>>>
>>>>>>
>>>>>> Though what we have in reality is the following:
>>>>>>
>>>>>>
>>>>>> /log4j-bom/pom.xml (`log4j-bom` module)
>>>>>>
>>>>>> /pom.xml (`log4j` module parented by `logging-parent`)
>>>>>>
>>>>>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>>>>>
>>>>>>
>>>>>> Ideally we should follow the Maven-advised approach and consume from
>> our
>>>>>>
>>>>>> BOM parented by `logging-parent`.
>>>>>>
>>>>>>
>>>>>> What do you think? Is my interpretation of the Maven-advised approach
>>>>>>
>>>>>> correct?
>>>>>>
>>>>>>
>>>>
>>
>>
Re: Consuming our own BOM
Posted by Volkan Yazıcı <vo...@yazi.ci>.
Mind somebody sharing the last state? Is it implemented, if so how and on
which branch(es)? Is it reverted? If so, totally or partially?
On Sun, May 29, 2022 at 9:53 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> That is OK. I have reverted your commit and am testing the build for a
> second time doing it the correct way.
>
> Ralph
>
> > On May 28, 2022, at 9:14 PM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > It worked, but I had to specify where the parent pom was in the
> submodules. Are you saying I could get the same effect by importing the bom
> in the parent pom? If so, that certainly seems easier.
> >
> > —
> > Matt Sicker
> >
> >> On May 28, 2022, at 18:15, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >>
> >> Why is this necessary? I would think having the parent import the
> bom/pom.xml should be enough.
> >>
> >> Ralph
> >>
> >>> On May 27, 2022, at 6:18 PM, Matt Sicker <bo...@gmail.com> wrote:
> >>>
> >>> To avoid rearranging all the directories, I'm moving the parent pom to
> >>> its own directory, moving the bom pom to the root, and updating the
> >>> rest of the poms to know where the old parent pom now is.
> >>>
> >>>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com> wrote:
> >>>>
> >>>> Agreed. I added the BOM POM later on and didn’t know of any
> established patterns for modules as BOMs weren’t used extensively quite yet
> at the time (and it was a Maven specific feature then, too; Spring ported
> the concept to Gradle later on, and now Gradle has a native concept of the
> same thing).
> >>>>
> >>>> —
> >>>> Matt Sicker
> >>>>
> >>>>> On May 19, 2022, at 10:33, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >>>>
> >>>> Yes, that would make sense. I am sure this happened simply because
> the bom pom.xml was introduced way after the first releases.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> >>>>
> >>>>
> >>>> Even though we provide a BOM module (`log4j-bom`), we don't consume it
> >>>>
> >>>> ourselves. Hence occasionally we end up publishing artifacts not
> included
> >>>>
> >>>> in the BOM. Consuming our own BOM decreases the chances of missing out
> >>>>
> >>>> artifacts in BOM, though doesn't totally eliminate the chances of that
> >>>>
> >>>> happening.
> >>>>
> >>>>
> >>>> When I read how Maven advises to structure the BOM module
> >>>>
> >>>> <
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
> >,
> >>>>
> >>>> I understand what needs to be in the case of Log4j is the following:
> >>>>
> >>>>
> >>>> /pom.xml (`log4j-bom` module)
> >>>>
> >>>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
> >>>>
> >>>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by
> `log4j`)
> >>>>
> >>>>
> >>>> Though what we have in reality is the following:
> >>>>
> >>>>
> >>>> /log4j-bom/pom.xml (`log4j-bom` module)
> >>>>
> >>>> /pom.xml (`log4j` module parented by `logging-parent`)
> >>>>
> >>>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
> >>>>
> >>>>
> >>>> Ideally we should follow the Maven-advised approach and consume from
> our
> >>>>
> >>>> BOM parented by `logging-parent`.
> >>>>
> >>>>
> >>>> What do you think? Is my interpretation of the Maven-advised approach
> >>>>
> >>>> correct?
> >>>>
> >>>>
> >>
>
>
Re: Consuming our own BOM
Posted by Ralph Goers <ra...@dslextreme.com>.
That is OK. I have reverted your commit and am testing the build for a second time doing it the correct way.
Ralph
> On May 28, 2022, at 9:14 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> It worked, but I had to specify where the parent pom was in the submodules. Are you saying I could get the same effect by importing the bom in the parent pom? If so, that certainly seems easier.
>
> —
> Matt Sicker
>
>> On May 28, 2022, at 18:15, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> Why is this necessary? I would think having the parent import the bom/pom.xml should be enough.
>>
>> Ralph
>>
>>> On May 27, 2022, at 6:18 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> To avoid rearranging all the directories, I'm moving the parent pom to
>>> its own directory, moving the bom pom to the root, and updating the
>>> rest of the poms to know where the old parent pom now is.
>>>
>>>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> Agreed. I added the BOM POM later on and didn’t know of any established patterns for modules as BOMs weren’t used extensively quite yet at the time (and it was a Maven specific feature then, too; Spring ported the concept to Gradle later on, and now Gradle has a native concept of the same thing).
>>>>
>>>> —
>>>> Matt Sicker
>>>>
>>>>> On May 19, 2022, at 10:33, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>
>>>> Yes, that would make sense. I am sure this happened simply because the bom pom.xml was introduced way after the first releases.
>>>>
>>>> Ralph
>>>>
>>>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>>>
>>>>
>>>> Even though we provide a BOM module (`log4j-bom`), we don't consume it
>>>>
>>>> ourselves. Hence occasionally we end up publishing artifacts not included
>>>>
>>>> in the BOM. Consuming our own BOM decreases the chances of missing out
>>>>
>>>> artifacts in BOM, though doesn't totally eliminate the chances of that
>>>>
>>>> happening.
>>>>
>>>>
>>>> When I read how Maven advises to structure the BOM module
>>>>
>>>> <https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>,
>>>>
>>>> I understand what needs to be in the case of Log4j is the following:
>>>>
>>>>
>>>> /pom.xml (`log4j-bom` module)
>>>>
>>>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>>>>
>>>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>>>
>>>>
>>>> Though what we have in reality is the following:
>>>>
>>>>
>>>> /log4j-bom/pom.xml (`log4j-bom` module)
>>>>
>>>> /pom.xml (`log4j` module parented by `logging-parent`)
>>>>
>>>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>>>
>>>>
>>>> Ideally we should follow the Maven-advised approach and consume from our
>>>>
>>>> BOM parented by `logging-parent`.
>>>>
>>>>
>>>> What do you think? Is my interpretation of the Maven-advised approach
>>>>
>>>> correct?
>>>>
>>>>
>>
Re: Consuming our own BOM
Posted by Matt Sicker <bo...@gmail.com>.
It worked, but I had to specify where the parent pom was in the submodules. Are you saying I could get the same effect by importing the bom in the parent pom? If so, that certainly seems easier.
—
Matt Sicker
> On May 28, 2022, at 18:15, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Why is this necessary? I would think having the parent import the bom/pom.xml should be enough.
>
> Ralph
>
>> On May 27, 2022, at 6:18 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> To avoid rearranging all the directories, I'm moving the parent pom to
>> its own directory, moving the bom pom to the root, and updating the
>> rest of the poms to know where the old parent pom now is.
>>
>>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> Agreed. I added the BOM POM later on and didn’t know of any established patterns for modules as BOMs weren’t used extensively quite yet at the time (and it was a Maven specific feature then, too; Spring ported the concept to Gradle later on, and now Gradle has a native concept of the same thing).
>>>
>>> —
>>> Matt Sicker
>>>
>>>> On May 19, 2022, at 10:33, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>> Yes, that would make sense. I am sure this happened simply because the bom pom.xml was introduced way after the first releases.
>>>
>>> Ralph
>>>
>>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>>
>>>
>>> Even though we provide a BOM module (`log4j-bom`), we don't consume it
>>>
>>> ourselves. Hence occasionally we end up publishing artifacts not included
>>>
>>> in the BOM. Consuming our own BOM decreases the chances of missing out
>>>
>>> artifacts in BOM, though doesn't totally eliminate the chances of that
>>>
>>> happening.
>>>
>>>
>>> When I read how Maven advises to structure the BOM module
>>>
>>> <https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>,
>>>
>>> I understand what needs to be in the case of Log4j is the following:
>>>
>>>
>>> /pom.xml (`log4j-bom` module)
>>>
>>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>>>
>>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>>
>>>
>>> Though what we have in reality is the following:
>>>
>>>
>>> /log4j-bom/pom.xml (`log4j-bom` module)
>>>
>>> /pom.xml (`log4j` module parented by `logging-parent`)
>>>
>>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>>
>>>
>>> Ideally we should follow the Maven-advised approach and consume from our
>>>
>>> BOM parented by `logging-parent`.
>>>
>>>
>>> What do you think? Is my interpretation of the Maven-advised approach
>>>
>>> correct?
>>>
>>>
>
Re: Consuming our own BOM
Posted by Ralph Goers <ra...@dslextreme.com>.
Why is this necessary? I would think having the parent import the bom/pom.xml should be enough.
Ralph
> On May 27, 2022, at 6:18 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> To avoid rearranging all the directories, I'm moving the parent pom to
> its own directory, moving the bom pom to the root, and updating the
> rest of the poms to know where the old parent pom now is.
>
> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com> wrote:
>>
>> Agreed. I added the BOM POM later on and didn’t know of any established patterns for modules as BOMs weren’t used extensively quite yet at the time (and it was a Maven specific feature then, too; Spring ported the concept to Gradle later on, and now Gradle has a native concept of the same thing).
>>
>> —
>> Matt Sicker
>>
>> On May 19, 2022, at 10:33, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> Yes, that would make sense. I am sure this happened simply because the bom pom.xml was introduced way after the first releases.
>>
>> Ralph
>>
>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>
>>
>> Even though we provide a BOM module (`log4j-bom`), we don't consume it
>>
>> ourselves. Hence occasionally we end up publishing artifacts not included
>>
>> in the BOM. Consuming our own BOM decreases the chances of missing out
>>
>> artifacts in BOM, though doesn't totally eliminate the chances of that
>>
>> happening.
>>
>>
>> When I read how Maven advises to structure the BOM module
>>
>> <https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>,
>>
>> I understand what needs to be in the case of Log4j is the following:
>>
>>
>> /pom.xml (`log4j-bom` module)
>>
>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>>
>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>
>>
>> Though what we have in reality is the following:
>>
>>
>> /log4j-bom/pom.xml (`log4j-bom` module)
>>
>> /pom.xml (`log4j` module parented by `logging-parent`)
>>
>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>
>>
>> Ideally we should follow the Maven-advised approach and consume from our
>>
>> BOM parented by `logging-parent`.
>>
>>
>> What do you think? Is my interpretation of the Maven-advised approach
>>
>> correct?
>>
>>
Re: Consuming our own BOM
Posted by Matt Sicker <bo...@gmail.com>.
To avoid rearranging all the directories, I'm moving the parent pom to
its own directory, moving the bom pom to the root, and updating the
rest of the poms to know where the old parent pom now is.
On Thu, May 19, 2022 at 3:08 PM Matt Sicker <bo...@gmail.com> wrote:
>
> Agreed. I added the BOM POM later on and didn’t know of any established patterns for modules as BOMs weren’t used extensively quite yet at the time (and it was a Maven specific feature then, too; Spring ported the concept to Gradle later on, and now Gradle has a native concept of the same thing).
>
> —
> Matt Sicker
>
> On May 19, 2022, at 10:33, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Yes, that would make sense. I am sure this happened simply because the bom pom.xml was introduced way after the first releases.
>
> Ralph
>
> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>
>
> Even though we provide a BOM module (`log4j-bom`), we don't consume it
>
> ourselves. Hence occasionally we end up publishing artifacts not included
>
> in the BOM. Consuming our own BOM decreases the chances of missing out
>
> artifacts in BOM, though doesn't totally eliminate the chances of that
>
> happening.
>
>
> When I read how Maven advises to structure the BOM module
>
> <https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>,
>
> I understand what needs to be in the case of Log4j is the following:
>
>
> /pom.xml (`log4j-bom` module)
>
> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>
> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>
>
> Though what we have in reality is the following:
>
>
> /log4j-bom/pom.xml (`log4j-bom` module)
>
> /pom.xml (`log4j` module parented by `logging-parent`)
>
> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>
>
> Ideally we should follow the Maven-advised approach and consume from our
>
> BOM parented by `logging-parent`.
>
>
> What do you think? Is my interpretation of the Maven-advised approach
>
> correct?
>
>
Re: Consuming our own BOM
Posted by Matt Sicker <bo...@gmail.com>.
Agreed. I added the BOM POM later on and didn’t know of any established patterns for modules as BOMs weren’t used extensively quite yet at the time (and it was a Maven specific feature then, too; Spring ported the concept to Gradle later on, and now Gradle has a native concept of the same thing).
—
Matt Sicker
> On May 19, 2022, at 10:33, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Yes, that would make sense. I am sure this happened simply because the bom pom.xml was introduced way after the first releases.
>
> Ralph
>
>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>
>> Even though we provide a BOM module (`log4j-bom`), we don't consume it
>> ourselves. Hence occasionally we end up publishing artifacts not included
>> in the BOM. Consuming our own BOM decreases the chances of missing out
>> artifacts in BOM, though doesn't totally eliminate the chances of that
>> happening.
>>
>> When I read how Maven advises to structure the BOM module
>> <https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>,
>> I understand what needs to be in the case of Log4j is the following:
>>
>> /pom.xml (`log4j-bom` module)
>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>
>> Though what we have in reality is the following:
>>
>> /log4j-bom/pom.xml (`log4j-bom` module)
>> /pom.xml (`log4j` module parented by `logging-parent`)
>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>>
>> Ideally we should follow the Maven-advised approach and consume from our
>> BOM parented by `logging-parent`.
>>
>> What do you think? Is my interpretation of the Maven-advised approach
>> correct?
>
Re: Consuming our own BOM
Posted by Ralph Goers <ra...@dslextreme.com>.
Yes, that would make sense. I am sure this happened simply because the bom pom.xml was introduced way after the first releases.
Ralph
> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> Even though we provide a BOM module (`log4j-bom`), we don't consume it
> ourselves. Hence occasionally we end up publishing artifacts not included
> in the BOM. Consuming our own BOM decreases the chances of missing out
> artifacts in BOM, though doesn't totally eliminate the chances of that
> happening.
>
> When I read how Maven advises to structure the BOM module
> <https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>,
> I understand what needs to be in the case of Log4j is the following:
>
> /pom.xml (`log4j-bom` module)
> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>
> Though what we have in reality is the following:
>
> /log4j-bom/pom.xml (`log4j-bom` module)
> /pom.xml (`log4j` module parented by `logging-parent`)
> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>
> Ideally we should follow the Maven-advised approach and consume from our
> BOM parented by `logging-parent`.
>
> What do you think? Is my interpretation of the Maven-advised approach
> correct?