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 :)



Thanks,
Robert

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 :)

Regards
JB

Le dim. 24 sept. 2023 à 22:54, Robert Varga <n...@hq.sk> 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