[
https://issues.apache.org/jira/browse/CAMEL-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418588#comment-15418588
]
ASF GitHub Bot commented on CAMEL-10222:
----------------------------------------
GitHub user nicolaferraro opened a pull request:
https://github.com/apache/camel/pull/1117
CAMEL-10222: New spring-boot starters
What's included:
- added new mojo to create starters for all components
- created starters and moved auto-configuration (with logging and
additional dependencies automatically fixed)
- added spring.provides and other static files to starters
- removed dependency on spring-boot from components
- added starters to bom (also, coap and grape were missing and have been
added .. also to the zip)
- changed integration tests to use the starters and a typical configuration
(they run successfully)
- changed examples
Future improvements:
- add a general bom for spring-boot applications
- basic integration tests run successfully, need to run unit tests for all
components (a lot of time) and fix dependencies (probably a spring-boot bom is
required to fix all dependencies)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/nicolaferraro/camel CAMEL-10222
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/1117.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1117
----
commit 4e57f519dd406733b81221a95695d560e57ce2f4
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-10T14:22:19Z
CAMEL-10222: Deleted spring-boot configuration from main projects
commit b8e0e82c72919aee58ff047a9a76ed433de64d1e
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-10T16:43:30Z
CAMEL-10222: Fixed configuration and moved spring-boot-starter
commit a985e27ff38408d49a5c40e6f774af4ebdb2462a
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-10T16:47:58Z
CAMEL-10222: New starters
commit 0d0e4084c03af0415a7aa1f61399f852550c5b9e
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-10T17:12:09Z
CAMEL-10222: Moved zipkin-starter to the components-starter module
commit da41024d60398b43a3df3f040d620163ba3e94c0
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-11T08:42:23Z
CAMEL-10222: Fixed factories and dependencies. Added license and notice
commit eb9f9f243a4fc93bc60d6b0eebbab7248c8f21b1
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-11T13:48:39Z
CAMEL-10222: Fixed factories and logging dependencies
commit 2395d6341f63ba2df317b7e9820f3a220ea2718c
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-11T16:57:16Z
CAMEL-10222: Tests passing
commit 104405ed903fe0ac64a615b4ab6bf603f43f59e2
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-12T06:59:38Z
CAMEL-10222: Updated poms to log4j v2 status
commit 5be65324d4a42e8620976575e6848abef9b90d4a
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-12T07:39:53Z
CAMEL-10222: Created camel-core-starter
commit dfa52d50c3e948d3e549d1d2a6d50c097f4158e6
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-12T08:37:36Z
CAMEL-10222: Added starters to BOM with missing components
commit b605b82bb9a06392b4b97754cf48f101e85b108e
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-12T09:16:55Z
CAMEL-10222: Removed redundant versions and source check
commit 8221f9d4de32f1a1e2527f778c05068ca7109aa4
Author: Nicola Ferraro <[email protected]>
Date: 2016-08-12T09:27:12Z
CAMEL-10222: Changed examples
----
> 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)
