[jira] [Commented] (CAMEL-10222) camel-spring-boot - New starters and BOMs

["Claus Ibsen (JIRA)" <ji...@apache.org>]

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

Claus Ibsen commented on CAMEL-10222:
-------------------------------------

We could let the camel maven plugin that generates the spring boot auto configuration source code

a)
check if there is an existing camel-xxx-starter module in the ../components-starter directory (to keep starters separated from regular components).
If not, then create a new directory with a basic pom.xml.

b)
generate/update the source code in the camel-xxx-starter instead of as today in the camel-xxx component

Then the regular camel components do not have any spring-boot source code anymore, and its 100% separated.

c)
Any camel-xx-starter that need any manual tweak for its pom.xml, we can then just do that. 

I see this as the simpler and more safter. Then there is not too much magic during the project build.



> 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
>            Reporter: Nicola Ferraro
>            Assignee: Nicola Ferraro
>
> 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)