[
https://issues.apache.org/jira/browse/CAMEL-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413129#comment-15413129
]
Claus Ibsen commented on CAMEL-10222:
-------------------------------------
I see your option 3 + 4 as something we should do later. Eg concentre on the
basics first to get all the starter modules and itests to work fine.
We can then later look at variants (maybe for the next release).
> 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)
