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 <n...@hq.sk> 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 <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 > >> > > >
