Re: The meaning of karaf-bom

[Matt Pavlovich]

+1 for JB’s 2-bom approach where the main bom reflects what is in the karaf 
dist, and a secondary bom for tests

karaf-bom  (should list all shipped jars from karaf, and jars from 
dependencies (or import _the dependency's bom_) installed in the dist.. felix, 
pax-logging, pax-web, etc
karaf-bom-test   (import karaf-bom, add test jars, etc)

Matt Pavlovich

> On Sep 28, 2023, at 8:57 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi,
> 
> I like the proposal of having different BOMs different of the use (for
> instance Quarkus has two different boms: one for application, one for
> test).
> 
> I can definitely create a bom module containing:
> - bom/stack
> - bom/application
> 
> If it works for you, I can create a Jira and then prepare this for Karaf 
> 4.5.0.
> 
> Thoughts ?
> 
> Regards
> JB
> 
> On Wed, Sep 27, 2023 at 9:46 PM Steven Huypens  
> wrote:
>> 
>> Hi Robert,
>> 
>> Thank you for clarifying the difference between both BOMs. I believe that
>> the current Karaf BOM incorporates elements from both types, whereas you
>> only require the library BOM.
>> 
>> In my opinion, it would be beneficial to create a distinct stack BOM. This
>> approach would enhance clarity for consumers. Additionally, by
>> consolidating all Maven version properties within this 'stack BOM,'
>> projects utilizing Karaf could easily synchronize their dependency versions
>> with those of Karaf, without the need to reference the entire Karaf parent
>> POM.
>> 
>> 
>> Kind regards,
>> Steven
>> 
>> On Wed, Sep 27, 2023 at 5:18 PM Robert Varga  wrote:
>> 
>>> On 27/09/2023 08.35, Jean-Baptiste Onofré wrote:
 Hi
>>> 
>>> Hello,
>>> 
 Not really imho : each project does the way it considers the best.
 
 For instance, quarkus is using a bop approach similar to Karaf: it
>>> exposes
 all dependencies in the BOM as a guarantee about the versions working
>>> fine.
 
 The idea in Karaf bom is to clearly state the versions verified in Karaf.
 Users can always override the versions, but the BOM guarantees the
 qualified versions.
>>> 
>>> Right, and nowadays there are lot more BOM-related resources on the web.
>>> 
>>> Researching what Maven4 will do (for the other email), I came across
>>> this: https://www.infoq.com/news/2023/06/maven-puzzlers-devoxxuk/
>>> 
>>> Which makes a distinction, making both our views correct:
>>> 
The library BOM - defines projects that are related to a single
>>> library. For example, the JUnit or Jackson BOM defines everything related
>>> to JUnit and nothing more
The stack BOM - Spring or Quarkus BOM bring all dependencies of
>>> various projects required for the given project to function. Each BOM
>>> contains a combination of versions that work best together
>>> 
>>> I meant to former while Karaf is doing the latter. Count myself educated :)
>>> 
>>> It might make sense to somehow also provide just a library BOM, but I
>>> struggle to define the use case where I would really need it :)
>>> 
>>> Thanks,
>>> Robert
>>> 
>>> 
 
 Regards
 JB
 
 Le dim. 24 sept. 2023 à 22:54, Robert Varga  a écrit :
 
> Hello,
> 
> One thing that strikes me is "Bill of Materials" as perceived by
>>> karaf-bom.
> 
> As it currently stands, karaf-bom includes all declarations of
> karaf.git/pom.xml.
> 
> As I understand the bill-of-materials concept under Maven, it should
> only list artifacts provided by a particular project, nothing more,
> nothing less.
> 
> In the latter regard, we should be only declaring org.apache.karaf
> artifacts in karaf-bom.
> 
>  From a downstream's perspective, there is a difference between
> importing karaf-bom (in which case the downstream takes the
> resposibility to align any shared depdendencies) and karaf.git/pom.xml
> (in which case I am trusting Karaf with a ton of dependencies).
> 
> Currently, there is no distinction between those two.
> 
> Is it fair to align karaf-bom with the above expectation (and hence not
> leak things like org.slfj4.api's version)?
> 
> As it stands there is no distinction, with this proposal current
> downstreams wishing to retain current state would scope=import
> karaf.git/pom.xml instead of karaf-bom (a change of maven coordinates)
> with no otherwise-observable change.
> 
> Does this make sense?
> 
> Regards,
> Robert
> 
 
>>> 

Re: The meaning of karaf-bom

[Jean-Baptiste Onofré]

Hi,

I like the proposal of having different BOMs different of the use (for
instance Quarkus has two different boms: one for application, one for
test).

I can definitely create a bom module containing:
- bom/stack
- bom/application

If it works for you, I can create a Jira and then prepare this for Karaf 4.5.0.

Thoughts ?

Regards
JB

On Wed, Sep 27, 2023 at 9:46 PM Steven Huypens  wrote:
>
> Hi Robert,
>
> Thank you for clarifying the difference between both BOMs. I believe that
> the current Karaf BOM incorporates elements from both types, whereas you
> only require the library BOM.
>
> In my opinion, it would be beneficial to create a distinct stack BOM. This
> approach would enhance clarity for consumers. Additionally, by
> consolidating all Maven version properties within this 'stack BOM,'
> projects utilizing Karaf could easily synchronize their dependency versions
> with those of Karaf, without the need to reference the entire Karaf parent
> POM.
>
>
> Kind regards,
> Steven
>
> On Wed, Sep 27, 2023 at 5:18 PM Robert Varga  wrote:
>
> > On 27/09/2023 08.35, Jean-Baptiste Onofré wrote:
> > > Hi
> >
> > Hello,
> >
> > > Not really imho : each project does the way it considers the best.
> > >
> > > For instance, quarkus is using a bop approach similar to Karaf: it
> > exposes
> > > all dependencies in the BOM as a guarantee about the versions working
> > fine.
> > >
> > > The idea in Karaf bom is to clearly state the versions verified in Karaf.
> > > Users can always override the versions, but the BOM guarantees the
> > > qualified versions.
> >
> > Right, and nowadays there are lot more BOM-related resources on the web.
> >
> > Researching what Maven4 will do (for the other email), I came across
> > this: https://www.infoq.com/news/2023/06/maven-puzzlers-devoxxuk/
> >
> > Which makes a distinction, making both our views correct:
> >
> > > The library BOM - defines projects that are related to a single
> > library. For example, the JUnit or Jackson BOM defines everything related
> > to JUnit and nothing more
> > > The stack BOM - Spring or Quarkus BOM bring all dependencies of
> > various projects required for the given project to function. Each BOM
> > contains a combination of versions that work best together
> >
> > I meant to former while Karaf is doing the latter. Count myself educated :)
> >
> > It might make sense to somehow also provide just a library BOM, but I
> > struggle to define the use case where I would really need it :)
> >
> > Thanks,
> > Robert
> >
> >
> > >
> > > Regards
> > > JB
> > >
> > > Le dim. 24 sept. 2023 à 22:54, Robert Varga  a écrit :
> > >
> > >> Hello,
> > >>
> > >> One thing that strikes me is "Bill of Materials" as perceived by
> > karaf-bom.
> > >>
> > >> As it currently stands, karaf-bom includes all declarations of
> > >> karaf.git/pom.xml.
> > >>
> > >> As I understand the bill-of-materials concept under Maven, it should
> > >> only list artifacts provided by a particular project, nothing more,
> > >> nothing less.
> > >>
> > >> In the latter regard, we should be only declaring org.apache.karaf
> > >> artifacts in karaf-bom.
> > >>
> > >>   From a downstream's perspective, there is a difference between
> > >> importing karaf-bom (in which case the downstream takes the
> > >> resposibility to align any shared depdendencies) and karaf.git/pom.xml
> > >> (in which case I am trusting Karaf with a ton of dependencies).
> > >>
> > >> Currently, there is no distinction between those two.
> > >>
> > >> Is it fair to align karaf-bom with the above expectation (and hence not
> > >> leak things like org.slfj4.api's version)?
> > >>
> > >> As it stands there is no distinction, with this proposal current
> > >> downstreams wishing to retain current state would scope=import
> > >> karaf.git/pom.xml instead of karaf-bom (a change of maven coordinates)
> > >> with no otherwise-observable change.
> > >>
> > >> Does this make sense?
> > >>
> > >> Regards,
> > >> Robert
> > >>
> > >
> >

Re: The meaning of karaf-bom

[Steven Huypens]

Hi Robert,

Thank you for clarifying the difference between both BOMs. I believe that
the current Karaf BOM incorporates elements from both types, whereas you
only require the library BOM.

In my opinion, it would be beneficial to create a distinct stack BOM. This
approach would enhance clarity for consumers. Additionally, by
consolidating all Maven version properties within this 'stack BOM,'
projects utilizing Karaf could easily synchronize their dependency versions
with those of Karaf, without the need to reference the entire Karaf parent
POM.


Kind regards,
Steven

On Wed, Sep 27, 2023 at 5:18 PM Robert Varga  wrote:

> On 27/09/2023 08.35, Jean-Baptiste Onofré wrote:
> > Hi
>
> Hello,
>
> > Not really imho : each project does the way it considers the best.
> >
> > For instance, quarkus is using a bop approach similar to Karaf: it
> exposes
> > all dependencies in the BOM as a guarantee about the versions working
> fine.
> >
> > The idea in Karaf bom is to clearly state the versions verified in Karaf.
> > Users can always override the versions, but the BOM guarantees the
> > qualified versions.
>
> Right, and nowadays there are lot more BOM-related resources on the web.
>
> Researching what Maven4 will do (for the other email), I came across
> this: https://www.infoq.com/news/2023/06/maven-puzzlers-devoxxuk/
>
> Which makes a distinction, making both our views correct:
>
> > The library BOM - defines projects that are related to a single
> library. For example, the JUnit or Jackson BOM defines everything related
> to JUnit and nothing more
> > The stack BOM - Spring or Quarkus BOM bring all dependencies of
> various projects required for the given project to function. Each BOM
> contains a combination of versions that work best together
>
> I meant to former while Karaf is doing the latter. Count myself educated :)
>
> It might make sense to somehow also provide just a library BOM, but I
> struggle to define the use case where I would really need it :)
>
> Thanks,
> Robert
>
>
> >
> > Regards
> > JB
> >
> > Le dim. 24 sept. 2023 à 22:54, Robert Varga  a écrit :
> >
> >> Hello,
> >>
> >> One thing that strikes me is "Bill of Materials" as perceived by
> karaf-bom.
> >>
> >> As it currently stands, karaf-bom includes all declarations of
> >> karaf.git/pom.xml.
> >>
> >> As I understand the bill-of-materials concept under Maven, it should
> >> only list artifacts provided by a particular project, nothing more,
> >> nothing less.
> >>
> >> In the latter regard, we should be only declaring org.apache.karaf
> >> artifacts in karaf-bom.
> >>
> >>   From a downstream's perspective, there is a difference between
> >> importing karaf-bom (in which case the downstream takes the
> >> resposibility to align any shared depdendencies) and karaf.git/pom.xml
> >> (in which case I am trusting Karaf with a ton of dependencies).
> >>
> >> Currently, there is no distinction between those two.
> >>
> >> Is it fair to align karaf-bom with the above expectation (and hence not
> >> leak things like org.slfj4.api's version)?
> >>
> >> As it stands there is no distinction, with this proposal current
> >> downstreams wishing to retain current state would scope=import
> >> karaf.git/pom.xml instead of karaf-bom (a change of maven coordinates)
> >> with no otherwise-observable change.
> >>
> >> Does this make sense?
> >>
> >> Regards,
> >> Robert
> >>
> >
>

Re: The meaning of karaf-bom

[Robert Varga]

On 25/09/2023 23.14, Steven Huypens wrote:

Hi Robert,


Hello Stephen,


Seems like a fair point to me, I agree the Karaf BOM should only list Karaf
dependencies. It would be nice though to be able to 'use' the library
versions Karaf is using for third party dependencies, without having to
import karaf.git/pom.xml. Any ideas for that?


Please keep in mind that starting from Maven 4.0, a new specific BOM
packaging

has been introduced. I have not looked into it, but it might be worth
looking at before making any changes.


Thanks for the pointer. That piece of maven documentation seems to have 
vastly improved since I last read everything there was on "scope=import" :)


As I understand, the forward compatibility warning is regarding the 
layout and relaxes the "BOM must be a parent" model outlined in the 
documentation. The interplay goes toward 
https://www.youtube.com/watch?v=KDAmlNKZJto (the best I could find off 
the top my head) and there was some implication with the new POM XSD -- 
I saw a presentation somewhere, where a lot of ceremony was removed from 
a multi-module pom.xml, but I don't have that handy.


Regards,
Robert





OpenPGP_signature
Description: OpenPGP digital signature

Re: The meaning of karaf-bom

[Steinar Bang]

> Jean-Baptiste Onofré :

> Not really imho : each project does the way it considers the best.

> For instance, quarkus is using a bop approach similar to Karaf: it exposes
> all dependencies in the BOM as a guarantee about the versions working fine.

> The idea in Karaf bom is to clearly state the versions verified in Karaf.

Yeah, and when I think back, I think this was what I wanted when I
originally requested a BOM.

The reason was that dependencies in my build was lagging a lot compared
to what was currently being used by the karaf runtime.

I wanted not to have to think about what version I should use.

And using something like renovator (which maybe didn't even exist back
then?), would risk me going past what the runtime was using and use
something newer and I didn't want that.

Re: The meaning of karaf-bom

[Robert Varga]

On 27/09/2023 08.35, Jean-Baptiste Onofré wrote:

Hi


Hello,


Not really imho : each project does the way it considers the best.

For instance, quarkus is using a bop approach similar to Karaf: it exposes
all dependencies in the BOM as a guarantee about the versions working fine.

The idea in Karaf bom is to clearly state the versions verified in Karaf.
Users can always override the versions, but the BOM guarantees the
qualified versions.


Right, and nowadays there are lot more BOM-related resources on the web.

Researching what Maven4 will do (for the other email), I came across 
this: https://www.infoq.com/news/2023/06/maven-puzzlers-devoxxuk/


Which makes a distinction, making both our views correct:


The library BOM - defines projects that are related to a single library. 
For example, the JUnit or Jackson BOM defines everything related to JUnit and 
nothing more
The stack BOM - Spring or Quarkus BOM bring all dependencies of various 
projects required for the given project to function. Each BOM contains a 
combination of versions that work best together


I meant to former while Karaf is doing the latter. Count myself educated :)

It might make sense to somehow also provide just a library BOM, but I 
struggle to define the use case where I would really need it :)


Thanks,
Robert




Regards
JB

Le dim. 24 sept. 2023 à 22:54, Robert Varga  a écrit :


Hello,

One thing that strikes me is "Bill of Materials" as perceived by karaf-bom.

As it currently stands, karaf-bom includes all declarations of
karaf.git/pom.xml.

As I understand the bill-of-materials concept under Maven, it should
only list artifacts provided by a particular project, nothing more,
nothing less.

In the latter regard, we should be only declaring org.apache.karaf
artifacts in karaf-bom.

  From a downstream's perspective, there is a difference between
importing karaf-bom (in which case the downstream takes the
resposibility to align any shared depdendencies) and karaf.git/pom.xml
(in which case I am trusting Karaf with a ton of dependencies).

Currently, there is no distinction between those two.

Is it fair to align karaf-bom with the above expectation (and hence not
leak things like org.slfj4.api's version)?

As it stands there is no distinction, with this proposal current
downstreams wishing to retain current state would scope=import
karaf.git/pom.xml instead of karaf-bom (a change of maven coordinates)
with no otherwise-observable change.

Does this make sense?

Regards,
Robert





OpenPGP_signature
Description: OpenPGP digital signature

Re: The meaning of karaf-bom

[Jean-Baptiste Onofré]

Hi

Not really imho : each project does the way it considers the best.

For instance, quarkus is using a bop approach similar to Karaf: it exposes
all dependencies in the BOM as a guarantee about the versions working fine.

The idea in Karaf bom is to clearly state the versions verified in Karaf.
Users can always override the versions, but the BOM guarantees the
qualified versions.

Regards
JB

Le dim. 24 sept. 2023 à 22:54, Robert Varga  a écrit :

> Hello,
>
> One thing that strikes me is "Bill of Materials" as perceived by karaf-bom.
>
> As it currently stands, karaf-bom includes all declarations of
> karaf.git/pom.xml.
>
> As I understand the bill-of-materials concept under Maven, it should
> only list artifacts provided by a particular project, nothing more,
> nothing less.
>
> In the latter regard, we should be only declaring org.apache.karaf
> artifacts in karaf-bom.
>
>  From a downstream's perspective, there is a difference between
> importing karaf-bom (in which case the downstream takes the
> resposibility to align any shared depdendencies) and karaf.git/pom.xml
> (in which case I am trusting Karaf with a ton of dependencies).
>
> Currently, there is no distinction between those two.
>
> Is it fair to align karaf-bom with the above expectation (and hence not
> leak things like org.slfj4.api's version)?
>
> As it stands there is no distinction, with this proposal current
> downstreams wishing to retain current state would scope=import
> karaf.git/pom.xml instead of karaf-bom (a change of maven coordinates)
> with no otherwise-observable change.
>
> Does this make sense?
>
> Regards,
> Robert
>

Re: The meaning of karaf-bom

[Steinar Bang]

And FWIW what I expected from the karaf BOM was that I would get build
dependency versions from whatever that version of karaf pulls in as
runtime dependencies.

That was what I requested, when I noticed that a lot of my dependencies
were ancient compared to what the current version of karaf was using.

So I think that maybe what the karaf BOM is today was what I wished for
and what I got...? (so maybe I don't want it to change any...?)

Re: The meaning of karaf-bom

[Steinar Bang]

> Steven Huypens :

> Please keep in mind that starting from Maven 4.0, a new specific BOM
> packaging
> 
> has been introduced. I have not looked into it, but it might be worth
> looking at before making any changes.

Interesting!

Thanks for the pointer!

Re: The meaning of karaf-bom

[Steven Huypens]

Hi Robert,

Seems like a fair point to me, I agree the Karaf BOM should only list Karaf
dependencies. It would be nice though to be able to 'use' the library
versions Karaf is using for third party dependencies, without having to
import karaf.git/pom.xml. Any ideas for that?


Please keep in mind that starting from Maven 4.0, a new specific BOM
packaging

has been introduced. I have not looked into it, but it might be worth
looking at before making any changes.

Kind regards,
Steven



On Sun, Sep 24, 2023 at 10:55 PM Robert Varga  wrote:

> Hello,
>
> One thing that strikes me is "Bill of Materials" as perceived by karaf-bom.
>
> As it currently stands, karaf-bom includes all declarations of
> karaf.git/pom.xml.
>
> As I understand the bill-of-materials concept under Maven, it should
> only list artifacts provided by a particular project, nothing more,
> nothing less.
>
> In the latter regard, we should be only declaring org.apache.karaf
> artifacts in karaf-bom.
>
>  From a downstream's perspective, there is a difference between
> importing karaf-bom (in which case the downstream takes the
> resposibility to align any shared depdendencies) and karaf.git/pom.xml
> (in which case I am trusting Karaf with a ton of dependencies).
>
> Currently, there is no distinction between those two.
>
> Is it fair to align karaf-bom with the above expectation (and hence not
> leak things like org.slfj4.api's version)?
>
> As it stands there is no distinction, with this proposal current
> downstreams wishing to retain current state would scope=import
> karaf.git/pom.xml instead of karaf-bom (a change of maven coordinates)
> with no otherwise-observable change.
>
> Does this make sense?
>
> Regards,
> Robert
>

Re: The meaning of karaf-bom

[Steinar Bang]

> Steinar Bang :

> For one of my projects I ended up restructuring the entire project,
> moving the current top pom down one level and create a new top level
> with two maven modules: a BOM and the project proper 
> https://github.com/steinarb/authservice :
>  authservice/
>  authservice/pom.xml
>  authservice/authservice-bom/
>  authservice/authservice-bom/pom.xml
>  authservice/authservice/
>  authservice/authservice/pom.xml

> The reason for this reorganization was to keep versions set by
> imported BOMs from leaking out into the BOM my project provides.

Note: I'm not sayin that the karaf BOM was to blame for this.

I'm just saying that doing something like



no.priv.bang.beans
beans-bom
${beans.version}
pom
import



into the effective POM of a BOM causes the dependencies of beans-bom (in
he example) to be included everywhere that BOM is imported.

Re: The meaning of karaf-bom

[Steinar Bang]

> Robert Varga :

> One thing that strikes me is "Bill of Materials" as perceived by karaf-bom.

> As it currently stands, karaf-bom includes all declarations of
> karaf.git/pom.xml.

> As I understand the bill-of-materials concept under Maven, it should
> only list artifacts provided by a particular project, nothing more,
> nothing less.
[snip!]
> Is it fair to align karaf-bom with the above expectation (and hence
> not leak things like org.slfj4.api's version)?

Note that while I'm the one who originally requested a karaf BOM, and
probably its first user, I have never actually looked at what it
does. :-)

But so far it has worked for me.  I use it to set versions of the
dependencies I actually use.

However, "leaking things" rang a bell with me.

For one of my projects I ended up restructuring the entire project,
moving the current top pom down one level and create a new top level
with two maven modules: a BOM and the project proper 
https://github.com/steinarb/authservice :
 authservice/
 authservice/pom.xml
 authservice/authservice-bom/
 authservice/authservice-bom/pom.xml
 authservice/authservice/
 authservice/authservice/pom.xml

The reason for this reorganization was to keep versions set by imported
BOMs from leaking out into the BOM my project provides.

The meaning of karaf-bom

[Robert Varga]

Hello,

One thing that strikes me is "Bill of Materials" as perceived by karaf-bom.

As it currently stands, karaf-bom includes all declarations of 
karaf.git/pom.xml.


As I understand the bill-of-materials concept under Maven, it should 
only list artifacts provided by a particular project, nothing more, 
nothing less.


In the latter regard, we should be only declaring org.apache.karaf 
artifacts in karaf-bom.


From a downstream's perspective, there is a difference between 
importing karaf-bom (in which case the downstream takes the 
resposibility to align any shared depdendencies) and karaf.git/pom.xml 
(in which case I am trusting Karaf with a ton of dependencies).


Currently, there is no distinction between those two.

Is it fair to align karaf-bom with the above expectation (and hence not 
leak things like org.slfj4.api's version)?


As it stands there is no distinction, with this proposal current 
downstreams wishing to retain current state would scope=import 
karaf.git/pom.xml instead of karaf-bom (a change of maven coordinates) 
with no otherwise-observable change.


Does this make sense?

Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature