camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Commented] (CAMEL-10222) camel-spring-boot - New starters and BOMs
Date Tue, 09 Aug 2016 07:42:20 GMT


Claus Ibsen commented on CAMEL-10222:

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

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.

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

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

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

> camel-spring-boot - New starters and BOMs
> -----------------------------------------
>                 Key: CAMEL-10222
>                 URL:
>             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=""
>          xmlns:xsi=""
>          xsi:schemaLocation="">
>     <modelVersion>4.0.0</modelVersion>
>     <groupId></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></groupId>
>   <artifactId>guava</artifactId>
>   <version>16.0.1</version> <!-- To override, again, the BOM version -->
> </dependency>
> <dependency>
>   <groupId></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
> {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

View raw message