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

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

Github user asfgit closed the pull request at:

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


> 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)

Reply via email to