[GitHub] camel pull request #1164: CAMEL-10222: New spring-boot BOM

[nicolaferraro]

Github user nicolaferraro closed the pull request at:

https://github.com/apache/camel/pull/1164


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] camel pull request #1164: CAMEL-10222: New spring-boot BOM

[nicolaferraro]

GitHub user nicolaferraro opened a pull request:

https://github.com/apache/camel/pull/1164

CAMEL-10222: New spring-boot BOM

I tried to run the integration tests (including the unit test part of each 
module) using the starters only, but I found out that a mixture of spring-boot 
dependencies and camel dependencies produce wrong classpaths, i.e. classpaths 
that include different versions of jetty-core and jetty-util-xxx (9.3 and 9.2). 
the same happens with submodules of activemq, hibernate, jackson and others.

Using Jetty 9.3 (the version supported by spring-boot) instead of the 9.2 
has some advantages in that users can possibly use other sb-compatible 
libraries in their applications.
The camel-jetty9 component had two issues with Jetty 9.3 (broken HTTPS 
support and a changed method signature). I solved both.

Being able to always use Netty 4.15 (same for sb and camel) would be also 
great. Unfortunately some modules (the one dependent on asynchttpclient) still 
need to work with Netty 4.0.x.
Netty will not be part of the BOM.

This means that, in order to use a component, people just need to add the 
starter to the application's pom, but if they include more starters, in some 
(hopefully rare) circumstances, the application will not work (just because two 
different versions of the same class cannot be present in a standard java 
classpath).

I evaluated different options before creating the final BOM:

1)
A BOM with lower precedence over the spring-boot BOM (this bom would simply 
be included by the users AFTER the spring-boot BOM declaration in their 
applications)

Drawbacks:
- Some modules require specific versions of some libraries. Eg. Spring-boot 
uses the cassandra v2 driver, while our component requires version 3. Cannot 
override it with a BOM with lower precedence.
- In general, there's no way to force a specific camel version for a 
particular library if spring-boot provides its own in the BOM (another example 
is activeMQ)

2)
A BOM with higher precedence over the spring-boot one

Drawbacks:
- Problems with gson and other libraries. Some of our modules use different 
versions of gson, so it should simply be excluded from the BOM and included in 
each starter
- If spring-boot adds eg. google guava in the future we will have more 
issues

3)
A brand new BOM, that includes all SAFE dependencies of the spring-boot BOM 
and then all safe dependencies of Camel parent.

Drawbacks:
- The user must use the org.apache.camel:camel-spring-boot-dependencies 
instead of the org.springframework.boot:spring-boot-dependencies
- Switching to a different version of spring-boot may be difficult (but 
many components would not work out of the box)

Advantages:
- Possibility to change any user dependency in the future (to fix issues)
- Possibility to choose camel versions over spring-boot versions and 
vice-versa
- Auto-generated from a reduced set of rules


I implemented the 3rd choice.
I also provided a separate camel-starter-parent to be able to change the 
libraries included in the starters without affecting the user BOM.

To create the full BOM I created a generator: a simple maven plugin that 
produces a flattened pom.xml file from information contained in a generator 
project, using inclusion/exclusion rules.
I had to put a small set (~20) of version numbers in a separate 
(camel-spring-boot-dm/pom.xml) file. The versions belonging to camel-parent 
should be aligned when the corresponding entry is changed.

I changed the integration tests to use the new structure:
- No module is failing when included in a spring-boot application (at 
least... before the rebase :D)
- Some modules (<20 / 220) are failing when running the unit tests from the 
integration framework. Many problems are simply related to the testing tool 
(it's difficult to make it stable). I'll investigate and correct real issues, 
if any.


I fixed many problems either by changing the starter's pom or changing the 
BOM, so now we have a more powerful tool for choosing the right libraries to 
include in the user apps.
Also, non-spring-boot users (eg. Karaf) are not impacted by the changes.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nicolaferraro/camel CAMEL-10222-P2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1164.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1164


commit 9914a683e0cd894b10c02250e33364681fc41753
Author: Nicola Ferraro 
Date:   2016-09-01T10:41:55Z

CAMEL-10222: Fixed some poms up to HBase

commit f5060038ae0167da3e87599c9fc6b01e1449cb7e
Author: