[ https://issues.apache.org/jira/browse/CAMEL-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15505834#comment-15505834 ]
ASF GitHub Bot commented on CAMEL-10222: ---------------------------------------- Github user nicolaferraro closed the pull request at: https://github.com/apache/camel/pull/1164 > 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)