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 <steven.huyp...@gmail.com> 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 <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 > > >> > > > > >
