Camel BOM

[Nicola Ferraro <ni...@gmail.com>]

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

Re: Camel BOM

[Claus Ibsen <cl...@gmail.com>]

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