camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-10222) camel-spring-boot - New starters and BOMs
Date Fri, 09 Sep 2016 13:25:20 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15477055#comment-15477055
] 

ASF GitHub Bot commented on CAMEL-10222:
----------------------------------------

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 <ni.ferraro@gmail.com>
Date:   2016-09-01T10:41:55Z

    CAMEL-10222: Fixed some poms up to HBase

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

    CAMEL-10222: Good configuration up to Jetty9

commit 1c153e005db8c06a49880da3f29eec192abaed93
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-02T11:43:38Z

    CAMEL-10222: Fixed resolution of wrong versions

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

    CAMEL-10222: Added more stuff to the BOM

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

    CAMEL-10222: Stable version

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

    CAMEL-10222: First generated BOM

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

    CAMEL-10222: First real BOM

commit 991e8b679a45b360773e5dc0bd70bb4546abd6f1
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-07T09:52:35Z

    CAMEL-10222: Simpler BOM

commit 10502bfdc4e61d2b59e472b546c7b470fa1cf65c
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-07T12:21:00Z

    CAMEL-10222: Pre-test release

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

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

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

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

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

    CAMEL-10222: Fixed several modules and starters

commit 2234e70f423cd4ddac9e54edb784a2fc923020d8
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-09T09:07:14Z

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

commit 2dc87ca8f8a7f5e30772ae5c0b19b7765439a151
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-09T09:30:55Z

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

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

    CAMEL-10222: Adding starters to the assembly

commit 4eda8803f524e2a52f323ef4f9fcef15f1b55cca
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-09T09:53:01Z

    CAMEL-10222: Simplified pom configuration

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

    CAMEL-10222: Fixing scala and servlet starters

commit 0ee01c19ac386a29a93973f088e8848b9a4aedd3
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-01T10:41:55Z

    CAMEL-10222: Fixed some poms up to HBase

commit 31b3eaaa7d8cfc87cebb640e2fde4a2abd806f6c
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-02T10:09:48Z

    CAMEL-10222: Good configuration up to Jetty9

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

    CAMEL-10222: Fixed resolution of wrong versions

commit 28cde2f90449055a498311351dc5168548131449
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-06T10:09:54Z

    CAMEL-10222: Added more stuff to the BOM

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

    CAMEL-10222: Stable version

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

    CAMEL-10222: First generated BOM

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

    CAMEL-10222: First real BOM

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

    CAMEL-10222: Simpler BOM

commit 8011560ec3de40b96923dbc2d9a3f3fa8afe5ec5
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-07T12:21:00Z

    CAMEL-10222: Pre-test release

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

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

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

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

commit 2855f2f03be451b76c7733213d59d29185c8d2ba
Author: Nicola Ferraro <ni.ferraro@gmail.com>
Date:   2016-09-08T15:23:21Z

    CAMEL-10222: Fixed several modules and starters

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

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

----


> 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}
> ***************************
> APPLICATION FAILED TO START
> ***************************
> 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
(v6.3.4#6332)

Mime
View raw message