ASF GitHub Bot commented on CAMEL-10222:

GitHub user nicolaferraro opened a pull request:


    CAMEL-10222: Conflicts-free springboot BOM

    I created a camel BOM without conflicts with the spring-boot one, as 
discussed in the mailing list.
    I removed the following modules from the list of starters (with reference 
to the previous PR):
    - IBatis and Quartz (v1): deprecated and having many issues when running 
unit tests in sb mode
    - Jclouds: Jclouds-core uses a specific version of Gson. Cannot work with 
the one in the spring-bom.
    - SparkRest: Internally using a class that is missing in the version of 
Jetty used by spring-boot.
    There are also other (10) modules having some problems, but issues might be 
caused by the testing environment. For example, the Cassandra module might work 
with v2 of the driver, but the tests cannot ensure this because unit tests 
include cassandra-all into the classpath and it is much more probable that 
cassandra-all cannot work in a spring-boot environment (and it must not).
    I kept that starters, as they should work: Ahc, Cassandra, Consul, Jgroups, 
Jibx, Jpa, Xmljson, Mongodb, MongodbGridfs, Mybatis.
    Waiting for feedbacks.

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

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

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


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

    This closes #1182
commit 5ca0fda09cb3cea7a2d73ec6ff660afed7f18e6c
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-01T10:41:55Z

    CAMEL-10222: Fixed some poms up to HBase

commit 2c8e289bce4ed2c7dc540b6f3168c8f38bfade7e
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-02T10:09:48Z

    CAMEL-10222: Good configuration up to Jetty9

commit 7f351389f96ecccc2d424964cd4506ff776b1f6e
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-02T11:43:38Z

    CAMEL-10222: Fixed resolution of wrong versions

commit 9de5089abe9640b7d15fc95d05a81b44f366c049
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-06T10:09:54Z

    CAMEL-10222: Added more stuff to the BOM

commit c39db2d390351807f4f0378b15d96bc3e7330e64
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-06T10:17:41Z

    CAMEL-10222: Stable version

commit f9c2a954f2efe0c5b09cc76e203c489c32ed261d
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-06T15:36:11Z

    CAMEL-10222: First generated BOM

commit b45ccadbd94371b2a3b25f964f04df8448e70595
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-07T09:46:56Z

    CAMEL-10222: First real BOM

commit 459b11fd34a6d59dbeb6eb8f9a78b6dc1eaf6cfd
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-07T09:52:35Z

    CAMEL-10222: Simpler BOM

commit 03a7e99bc6fc57ae98cea7ea5a62979466f2a1ea
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-07T12:21:00Z

    CAMEL-10222: Pre-test release

commit b12445607a8a1a8797e07bb35cb989cd1d160a35
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-07T14:37:23Z

    CAMEL-10222: First working version (no unit tests)

commit 08791341466686285b9a5e8c948379973be3f7ba
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-08T09:52:32Z

    CAMEL-10222: Fixing compatibility with Jetty 9.3 (provided with spring-boot)

commit 046156cee90232d04db857cff49390dae833bf97
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-08T15:23:21Z

    CAMEL-10222: Fixed several modules and starters

commit 993e57830eb2e79c81d3b6377c44389f54aa386c
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-09T09:07:14Z

    CAMEL-10222: Rewriting the examples to use the new spring-boot BOM

commit 107e6e80984c0b1d2b7deeaf983bc6622578ab5c
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-09T09:30:55Z

    CAMEL-10222: Rewriting the archetype to use the new BOM

commit 702dd979ebe1871ff256d128cb6935ef3ac3deee
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-09T09:42:31Z

    CAMEL-10222: Adding starters to the assembly

commit 2292d2d7bbca40878dc958ef68924ce9abec41ea
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-09T09:53:01Z

    CAMEL-10222: Simplified pom configuration

commit fc44cce212ff267a75448138d6f572a6f0e27488
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-09T11:29:48Z

    CAMEL-10222: Fixing scala and servlet starters

commit 923c44bcb1021cea632e47b77db775d60e82c59c
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-09T12:29:16Z

    CAMEL-10222: Aligning libraries with master

commit 281fbfd89142adbbfaca5b277af6f22550c36525
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-09T13:17:46Z

    CAMEL-10222: Source check

commit b1dfcabe3151286bc7096d796037a57baa9a002c
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-09T13:17:46Z

    CAMEL-10222: New conflicts-free BOM

commit 02d0f68b1842cedee2018c0712c3e40bf7fd6f8c
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-20T07:05:31Z

    CAMEL-10222: Updated versions in spring-boot BOM

commit ccb201a2fa0827e1b008e499e0b801158ff798f3
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-20T07:52:45Z

    CAMEL-10222: Updated examples

commit a0cacd9caa32af9de4b48b38c91100d686512032
Author: Nicola Ferraro <ni.ferr...@gmail.com>
Date:   2016-09-20T08:11:53Z

    CAMEL-10222: Aligned Hazelcast


> camel-spring-boot - New starters and BOMs
> -----------------------------------------
>                 Key: CAMEL-10222
>                 URL: https://issues.apache.org/jira/browse/CAMEL-10222
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-spring-boot
>            Reporter: Nicola Ferraro
>            Assignee: Nicola Ferraro
>             Fix For: 2.18.0
> It would be great if all camel components could be mixed-in in a spring-boot 
> application without having to worry about dependencies.
> This would allow users to choose the camel components in a tool like forge on 
> fabric8 or spring initializr to produce a base artifact. Writing camel routes 
> will be the only task left to the user. 
> Unfortunately, integration tests have shown that there are many (small, 
> trivial) issues that need to be fixed before people can use a component with 
> spring-boot (list follows).
> A possible solution that will provide a better experience with spring-boot 
> would be:
> - Providing a new spring-boot bom
> - Providing a spring-boot-starter project for each camel component
> A user application pom will look like the following:
> {code:xml}
> <project xmlns="http://maven.apache.org/POM/4.0.0";
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>     <modelVersion>4.0.0</modelVersion>
>     <groupId>com.company</groupId>
>     <artifactId>myapp</artifactId>
>     <version>1.0</version>
>     <dependencyManagement>
>         <dependencies>
>             <dependency>
>                 <groupId>org.springframework.boot</groupId>
>                 <artifactId>spring-boot-dependencies</artifactId>
>                 <version>xxx</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
>             <dependency>
>                 <groupId>org.apache.camel</groupId>
>                 <artifactId>camel-spring-boot-dependencies</artifactId>
>                 <version>xxx</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
>         </dependencies>
>     </dependencyManagement>
>     <dependencies>
>         <dependency>
>             <groupId>org.apache.camel</groupId>
>             <artifactId>camel-starter-docker</artifactId>
>             <!-- camel-spring-boot-starter-docker is a better (but longer) 
> option, according to the s.b. documentation -->
>         </dependency>
>         <!-- Others -->
>         <dependency>
>             <groupId>org.apache.camel</groupId>
>             <artifactId>camel-starter-http</artifactId>
>         </dependency>
>     </dependencies>
> </project>
> {code}
> As suggested by [~chirino], the creation of such starters (and of the bom) 
> could be automated. Rules for creating such artifacts will be (at least) the 
> following:
> *0) Basic*
> The spring-boot-bom will be derived from _camel-parent_, with some exceptions 
> to solve particular issues. Most of the starters will just include a 
> dependency on the artifact they refer to.
> *1) Logging*
> Logging issues have been found during integration tests, but they will be 
> solved on the main artifacts (see CAMEL-10217). The starter generator will 
> just check that logging implementation are missing from the artifact to 
> prevent conflicts with slf4j-logback (used by spring-boot-starter).
> *2) Transitive overrides*
> Using the current implementation (with _camel-parent_ in the BOM), whenever a 
> component requires a library that is different from the one declared in 
> _camel-parent_, some hacks should be done, because the definition in the BOM 
> takes precedence.
> Eg. An user wants to use camel-jclouds, but instead of the pretty:
> {code:xml}
> <dependency>
>   <groupId>org.apache.camel</groupId>
>   <artifactId>camel-jclouds</artifactId>
> </dependency>
> {code}
> He will end up with the following declaration in his application pom:
> {code:xml}
> <dependency>
>   <groupId>org.apache.camel</groupId>
>   <artifactId>camel-jclouds</artifactId>
>   <exclusions>
>     <exclusion>
>       <groupId>org.slf4j</groupId>
>       <artifactId>slf4j-log4j12</artifactId>
>     </exclusion>
>   </exclusions>
> </dependency>
> <dependency>
>   <groupId>com.google.guava</groupId>
>   <artifactId>guava</artifactId>
>   <version>16.0.1</version> <!-- To override, again, the BOM version -->
> </dependency>
> <dependency>
>   <groupId>com.google.inject</groupId>
>   <artifactId>guice</artifactId>
>   <version>3.0</version> <!-- To override, again, the BOM version -->
> </dependency>
> {code}
> As a solution to this problem, if there are at least two components requiring 
> eg. a different version of guava, guava will not be included in the 
> spring-boot bom, instead the specific version will be enforced on each 
> starter (for all components using guava).
> Of course, this will not prevent issues when two components requiring 
> different versions of guava will be used in the same user application. I 
> think this issue cannot be avoided in applications with a standard 
> classloader.
> *3) API implementations*
> In many cases, spring-boot detects the presence of a particular api in the 
> classpath and expects an implementation is present. This happens for example 
> with the bean validation api:
> {noformat}
> ***************************
> ***************************
> Description:
> The Bean Validation API is on the classpath but no implementation could be 
> found
> Action:
> Add an implementation, such as Hibernate Validator, to the classpath
> {noformat}
> The starters will include eg. the Hibernate Validator each time it is 
> required to start the application.
> *4) Optional dependencies as variants*
> Starters are often used to provide a full stack for some higher level 
> libraries/api.
> Eg. The JTA api can be provided in spring with three starters (as of 1.4.0):
> - spring-boot-starter-jta-atomikos
> - spring-boot-starter-jta-bitronix
> - spring-boot-starter-jta-narayana
> Each starter will include everything that is necessary in terms of libraries 
> and auto-configuration for the particular implementation.
> Having such an automated tool for generating poms, we could create starters 
> like:
> - camel-starter-rest-netty
> - camel-starter-rest-jetty
> - camel-starter-rest-undertow
> Each one having everything needed to run routes described using rest dsl 
> (auto-configuration included. It will probably be developed on the main 
> component).
> Similarly we can have:
> - camel-starter-jms
> - camel-starter-jms-jta
> The latter providing a preferred implementation and autoconfiguration (such 
> as Narayana).
> *5) Tests*
> Each configuration will be checked by the already existing spring-boot 
> integration tests. Support will be added for executing specific tests related 
> to the a particular starter configuration, if needed.
> In case of dependencies enforced by both camel-parent and spring-boot (with 
> different versions), the _camel-spring-boot_ BOM will use the spring-boot 
> version. Problems will be highlighted by integration tests.
> I started this Jira mainly to check if this feature can improve the user 
> experience and if the points I highlighted are sound, before starting the 
> implementation.
> Probably there are also other issues/use-cases that I didn't cover in my list.

This message was sent by Atlassian JIRA

Reply via email to