+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é <j...@nanthrax.net> 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 <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 >>>>> >>>> >>>
