You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Zoran Regvart <zo...@regvart.com> on 2017/09/03 19:32:15 UTC

Should we combine Spring Boot starters

Hi Cameleers,
I'm wondering if it would be simpler to combine all starters into a
single artifact and what would the downside of that be?

So instead of having a number of *-starter artifacts, we could bundle
all *AutoConfiguration classes in camel-spring-boot-starter artifact
and guard them with @ConditionalOnClass or we could even create a
@ConditionalOnCamelComponent that looks into META-INF for component
being present on the classpath.

This could help us by having a much smaller number of artifacts to
build/deploy and could open support for Spring Boot 1.5 and 2 as we
could have spring-boot-2-starter with Spring Boot 2 specific code
there.

Does this make sense?

zoran
-- 
Zoran Regvart

Re: Should we combine Spring Boot starters

Posted by Claus Ibsen <cl...@gmail.com>.
Hi

I do like how it is today where there is a -starter for each Camel
component we support on Spring Boot. That makes it easy to see what we
support and have.

Spring Boot v1.5 is the last 1.x release. Spring Boot is not like an
app server like Tomcat, JBoss etc where you host many apps in that app
server where you can run different Camel versions side by side. So
users that build a new application just pick spring boot 2.x and the
Camel release that works with it.

Camel 2.20.0 was intended as a bit quicker than usual release cycle,
to get a release out that is a bit faster and have a bit better spring
lifecycle / camel spring boot configuration etc, and then the usual X
new components.

So when Spring Boot 2.0 is out, we can then fairly quickly start on
upgrading to that for 2.21.

And besides a one giant component with all the Camel components wont
be able to compile with all those JAR dependencies and some will have
clashes etc. And I think if it could, it will slowdown SB as it has
now 200+ condition's and whatnot to check on startup etc.

A novel idea, keep them coming Zoran, but I would like to keep what we
do today more stable and as-is. Our end users are familiar with that
there is -starter component for each of those Camel component you can
use on SB.








On Sun, Sep 3, 2017 at 9:32 PM, Zoran Regvart <zo...@regvart.com> wrote:
> Hi Cameleers,
> I'm wondering if it would be simpler to combine all starters into a
> single artifact and what would the downside of that be?
>
> So instead of having a number of *-starter artifacts, we could bundle
> all *AutoConfiguration classes in camel-spring-boot-starter artifact
> and guard them with @ConditionalOnClass or we could even create a
> @ConditionalOnCamelComponent that looks into META-INF for component
> being present on the classpath.
>
> This could help us by having a much smaller number of artifacts to
> build/deploy and could open support for Spring Boot 1.5 and 2 as we
> could have spring-boot-2-starter with Spring Boot 2 specific code
> there.
>
> Does this make sense?
>
> zoran
> --
> Zoran Regvart



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2