Re: Getting ready for Apache Camel 2.18 Release

[Nicola Ferraro]

Hi Claus, I started working on that this morning.
I think I'll provide the new BOM and related updates early next week.





On Fri, Sep 16, 2016 at 9:38 AM, Claus Ibsen  wrote:

> Hi Nicola
>
> How does your calendar look like? I wonder if you have time to work
> more on this Camel and Spring Boot stuff?
>
> I am afraid this one is the major task we have left before we can get
> started on the Camel 2.18 release and IMHO first class Spring Boot
> support is a major win/goal for Camel.
>
> So the work is very important, and its been awesome what you have
> done. Really love that we have integration tests, and also separated
> the auto stuff code from the existing components so there is clean
> separation.
>
>
>
>
> On Wed, Sep 14, 2016 at 3:32 PM, Nicola Ferraro 
> wrote:
> > Well, it was one of the drawbacks of the approach. Forcing users to
> include
> > *only* the camel BOM allows us to completely control the dependencies,
> but
> > it's probably a too strict requirement for users.
> >
> > We can also provide a option 1+2: i.e. a auto-generated Camel BOM without
> > any conflict with the spring-boot one (conflicts verified by eg. a maven
> > plugin).
> > Users will be able to import it in any order but, of course, some
> > components will not work because we cannot override what's in the
> > spring-boot BOM (unless the users force a different version in their pom,
> > but it's up to them).
> >
> > It makes more sense..
> > What do you think about it?
> >
> >
> >
> > On Wed, Sep 14, 2016 at 9:46 AM, Claus Ibsen 
> wrote:
> >
> >> Hi Nicola
> >>
> >> Great work on all this Spring Boot starter stuff.
> >>
> >> I would like to discuss/hear more about the #1 option you listed on
> >> https://github.com/apache/camel/pull/1164
> >>
> >> I think that end users would really prefer their Spring Boot
> >> applications to be "pure" spring boot by having the Spring Boot BOM
> >> first and then possible the Camel BOM imported as 2nd.
> >>
> >> I am okay if there is some Camel components that would not work with
> >> Spring Boot such as Cassandra or others. For ActiveMQ then Camel only
> >> uses that for testing camel-jms component and do not have a strong
> >> dependency on the version. So end users should likely use the Spring
> >> Boot ActiveMQ starter.
> >>
> >>
> >>
> >> On Mon, Sep 12, 2016 at 11:10 AM, Nicola Ferraro 
> >> wrote:
> >> > I've worked on the spring-boot starters and BOM topic and opened a PR
> >> > recently. You can find a summary here [
> >> > https://issues.apache.org/jira/browse/CAMEL-10222] and this is latest
> >> PR:
> >> > https://github.com/apache/camel/pull/1164.
> >> >
> >> > Basically, the aim is allowing users to add camel components to their
> >> > application by just adding the corresponding "xx-starter" project to
> >> their
> >> > POM. This can be useful also for initializer tools like
> >> > https://start.spring.io/ and the likes, to create skeleton of
> >> applications
> >> > that just work, without having to worry about wrong transitive
> >> dependencies.
> >> > Starter projects take care of, eg. excluding unwanted logging
> libraries
> >> and
> >> > including eg. libraries that are provided in other contexts.
> >> >
> >> > The new BOM part is a semi-automated way to generate a BOM for the
> users
> >> > that fixes incompatibilities between the camel-parent BOM and the
> >> > spring-boot-dependencies BOM. They currently differ for the minor (and
> >> > sometimes major) version of many libraries, including eg. Jetty,
> >> ActiveMQ,
> >> > Hibernate Validator, Cassandra driver, etc. Both BOMs also include
> >> specific
> >> > versions of common libraries like guava, guice and gson that take
> >> > precedence over the transitive versions required by the starters,
> >> resulting
> >> > in camel components not working correctly.
> >> > The new BOM (partly generated) should be used in place of the two
> >> > Camel+Spring-boot BOMs to avoid such issues.
> >> >
> >> > I understand that this is a major change, so I ask your feedback about
> >> the
> >> > problem (do we want to have this feature to solve these problems for
> >> > users?) and the solution.
> >> >
> >> > Thanks
> >> >
> >> > On Fri, Sep 9, 2016 at 6:08 PM, Quinn Stevenson <
> >> qu...@pronoia-solutions.com
> >> >> wrote:
> >> >
> >> >> Thanks for taking a look at the PR Thomas - I really appreciate the
> >> >> feedback.
> >> >>
> >> >> 1) The parent pom was wrong because I created this PR before the
> change
> >> >> from 2.18-SNAPSHOT to 2.18.0-SNAPSHOT took place - it’s been out
> there a
> >> >> while
> >> >> 2) My bad on the READMEmd - you can probably tell where I copied the
> >> >> example from to get started :-).  I’ll get working on that to clean
> it
> >> up
> >> >> 3)  I really struggled with this - what example to use.  I thought a
> >> >> little about replacing JMS with something else, but I wasn’t quite
> sure
> >> >> what 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi Nicola

How does your calendar look like? I wonder if you have time to work
more on this Camel and Spring Boot stuff?

I am afraid this one is the major task we have left before we can get
started on the Camel 2.18 release and IMHO first class Spring Boot
support is a major win/goal for Camel.

So the work is very important, and its been awesome what you have
done. Really love that we have integration tests, and also separated
the auto stuff code from the existing components so there is clean
separation.




On Wed, Sep 14, 2016 at 3:32 PM, Nicola Ferraro  wrote:
> Well, it was one of the drawbacks of the approach. Forcing users to include
> *only* the camel BOM allows us to completely control the dependencies, but
> it's probably a too strict requirement for users.
>
> We can also provide a option 1+2: i.e. a auto-generated Camel BOM without
> any conflict with the spring-boot one (conflicts verified by eg. a maven
> plugin).
> Users will be able to import it in any order but, of course, some
> components will not work because we cannot override what's in the
> spring-boot BOM (unless the users force a different version in their pom,
> but it's up to them).
>
> It makes more sense..
> What do you think about it?
>
>
>
> On Wed, Sep 14, 2016 at 9:46 AM, Claus Ibsen  wrote:
>
>> Hi Nicola
>>
>> Great work on all this Spring Boot starter stuff.
>>
>> I would like to discuss/hear more about the #1 option you listed on
>> https://github.com/apache/camel/pull/1164
>>
>> I think that end users would really prefer their Spring Boot
>> applications to be "pure" spring boot by having the Spring Boot BOM
>> first and then possible the Camel BOM imported as 2nd.
>>
>> I am okay if there is some Camel components that would not work with
>> Spring Boot such as Cassandra or others. For ActiveMQ then Camel only
>> uses that for testing camel-jms component and do not have a strong
>> dependency on the version. So end users should likely use the Spring
>> Boot ActiveMQ starter.
>>
>>
>>
>> On Mon, Sep 12, 2016 at 11:10 AM, Nicola Ferraro 
>> wrote:
>> > I've worked on the spring-boot starters and BOM topic and opened a PR
>> > recently. You can find a summary here [
>> > https://issues.apache.org/jira/browse/CAMEL-10222] and this is latest
>> PR:
>> > https://github.com/apache/camel/pull/1164.
>> >
>> > Basically, the aim is allowing users to add camel components to their
>> > application by just adding the corresponding "xx-starter" project to
>> their
>> > POM. This can be useful also for initializer tools like
>> > https://start.spring.io/ and the likes, to create skeleton of
>> applications
>> > that just work, without having to worry about wrong transitive
>> dependencies.
>> > Starter projects take care of, eg. excluding unwanted logging libraries
>> and
>> > including eg. libraries that are provided in other contexts.
>> >
>> > The new BOM part is a semi-automated way to generate a BOM for the users
>> > that fixes incompatibilities between the camel-parent BOM and the
>> > spring-boot-dependencies BOM. They currently differ for the minor (and
>> > sometimes major) version of many libraries, including eg. Jetty,
>> ActiveMQ,
>> > Hibernate Validator, Cassandra driver, etc. Both BOMs also include
>> specific
>> > versions of common libraries like guava, guice and gson that take
>> > precedence over the transitive versions required by the starters,
>> resulting
>> > in camel components not working correctly.
>> > The new BOM (partly generated) should be used in place of the two
>> > Camel+Spring-boot BOMs to avoid such issues.
>> >
>> > I understand that this is a major change, so I ask your feedback about
>> the
>> > problem (do we want to have this feature to solve these problems for
>> > users?) and the solution.
>> >
>> > Thanks
>> >
>> > On Fri, Sep 9, 2016 at 6:08 PM, Quinn Stevenson <
>> qu...@pronoia-solutions.com
>> >> wrote:
>> >
>> >> Thanks for taking a look at the PR Thomas - I really appreciate the
>> >> feedback.
>> >>
>> >> 1) The parent pom was wrong because I created this PR before the change
>> >> from 2.18-SNAPSHOT to 2.18.0-SNAPSHOT took place - it’s been out there a
>> >> while
>> >> 2) My bad on the READMEmd - you can probably tell where I copied the
>> >> example from to get started :-).  I’ll get working on that to clean it
>> up
>> >> 3)  I really struggled with this - what example to use.  I thought a
>> >> little about replacing JMS with something else, but I wasn’t quite sure
>> >> what to use.  It gets a little more complicated because of the two JVMs
>> >> (one for Karaf and one for the bootstrap code).  Anyway, if you have a
>> >> “good” test route and what you’d like to see happen for testing, I’d
>> really
>> >> like to see it and I’ll try and use that instead.
>> >> 4)  I’m not sure where I came up with the name of the example - but
>> you’re
>> >> right - I’ll change it to example-camel-test-karaf
>> >> 5) I’ll