Hi Nicola Thanks for writing up this information.
Good to hear the BOM is auto generated. I never really liked how the parent/pom.xml has been infested with a bunch of various dependencies that we don't really care/use at Apache Camel, for example Hibernate. And why do we import optaplanner BOM in it too etc. Down the road I would like to cleanup this parent/pom.xml And only let parent/pom.xml contain the <properties> with the versions, the camel artifacts, and a few common core dependencies. Another thing for Camel 3.0 to cleanup On Tue, Sep 26, 2017 at 4:23 PM, Nicola Ferraro <[email protected]> wrote: > Hi devs, > I've been working on the boot2 branch with Claus last week in order to > investigate how to support spring-boot 1 & 2 in the same Camel version. We > will decide later (2.21) if we want to support both versions together or > just make Camel 2.20 to support spring-boot 1.5.x and Camel 2.21 for > spring-boot 2.x only. > > Btw, after doing some tests with both versions, I noticed that the > alignment issues that we had with spring-boot 1.4.x and Camel are > disappearing in later versions of spring-boot, mainly because the holes in > org.springframework.boot:spring-boot-dependencies have been progressively > filled up. I'm trying to include some other minor fixes in that pom for > spring-boot 2... > > This practically means (and some people already know) that it's not always > mandatory to include "camel-spring-boot-dependencies" into the dependency > management section of every end-user application. Plain Camel starters can > be just added to a normal spring-boot application. If this was not the > case, we would need a camel-spring-boot-dependencies2 pom to align > dependencies in the boot2 branch... > > Given that, I've created under "/bom" a org.apache.camel:camel-bom > artifact. This is not related to spring-boot, it's supposed to be just a > list of Camel artifacts published into maven central (at least, the ones > useful for the end user). It's literally a BOM (Bill Of Material) that we > provide. > > It's different from camel-parent because it contains only Camel modules and > not third-party modules, so it can be included in a end-user application or > also into another library without creating conflicts with other BOMs w.r.t. > transitive dependencies. > > It is generated and maintained automatically by filtering out what's > "not-our-stuff" from camel-parent. > > We have been asked to provide a Camel BOM like that for start.spring.io few > months ago, but I definitely think it's something that can be useful in > other contexts in the future, other than spring-boot. > > Thoughts? > > Nicola -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
