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