Re: Getting ready for Apache Camel 2.18 Release

[Gregor Zurowski]

I was finally able to complete the process without issues, as well as
closing the artifact repository without any errors.  I will send out
the vote for 2.18.0 shortly.

Thanks,
Gregor


On Tue, Oct 4, 2016 at 9:58 PM, Gregor Zurowski
 wrote:
> Hi Everyone:
>
> Unfortunately, closing the staging repository did not succeed and was
> aborted with the following error message:
>
> "Missing MD5: 
> '/org/apache/camel/camel-optaplanner-starter/2.18.0/camel-optaplanner-starter-2.18.0.pom.md5'"
>
> It seems that something went wrong during the upload to Nexus.  I will
> restart the release process and see if it solves the issue.
>
> Thanks,
> Gregor
>
>
> On Tue, Oct 4, 2016 at 9:06 PM, Gregor Zurowski
>  wrote:
>> Hi Everyone:
>>
>> I was finally able to create the release without any timeout errors
>> and I am currently closing the staging repository.  I will send out
>> the vote for the release candidate shortly.
>>
>> Thanks,
>> Gregor
>>
>>
>> On Tue, Oct 4, 2016 at 9:03 AM, Gregor Zurowski
>>  wrote:
>>> Hi Everyone:
>>>
>>> Unfortunately the second attempt to release the 2.18.0 RC failed close
>>> towards the end of the build process due to connectivity issues with
>>> the Apache repository server.  I have just started the release process
>>> once again and will post updates to this thread.
>>>
>>> Thanks,
>>> Gregor
>>>
>>>
>>> On Mon, Oct 3, 2016 at 9:35 PM, Claus Ibsen  wrote:
 Hi

 Gregor is currently working on the 2.18.0 RC, but there was a
 network/timeout issue yesterday, so he has to restart again, which he
 is doing today.

 The release is still in the works, so please don't do major
 refactorings on the master branch ;)


 On Sun, Aug 28, 2016 at 5:28 AM, Claus Ibsen  wrote:
> Hi
>
> Hope everybody had good summer vacation. I had my vacation in parts
> and have next week as PTO.
>
> We should get started to close down on the upcoming Camel 2.18 release.
>
>
> There is some outstanding work (in no particular order)
>
> 1)
> Finish the spring boot stuff with the starter components.
> Nicola comes back from PTO and will work on this.
>
> 2)
> rest-dsl to support calling REST services. I am working on this and
> have some outstanding work still around binding and other
> improvements.
>
> 3)
> Tidy up the log4j v2 upgrade. Some of the examples do not start with
> the jetty plugin.
>
> 4)
> Migrate the last wiki pages to adoc files. There is not so many pages
> left and you can find a report when running camel-catalog build that
> output what is missing.
>
> This will help us with a base-line for maintaining the documentation
> going forward in the source code adoc files instead of wiki, and we
> can then generate a new website and documentation for the following
> release (2.19 or 3.0) etc. But this is a discussion we should IMHO
> take post 2.18.
>
> 5)
> camel-test-karaf module. This module is in the works but could use
> some review and finishing so its easier to use for end users.
>
> Notice the existing camel-test-blueprint is still favored for doing
> unit tests which you can run fast and easily debug. The new
> camel-test-karaf is for running integration tests in a running karaf
> instance.
>
> 6)
> We should look at the JIRA tickets that are assigned to 2.18.0 and try
> to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
> releases.
>
> 7)
> Keep an eye on the CI server to make sure the tests are green.
> https://builds.apache.org/view/A-D/view/Camel/
>
>
> If all goes well then hopefully in 2-3 weeks we are ready to cut the 
> 2.18.0 RC.
>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



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

Re: Getting ready for Apache Camel 2.18 Release

[Gregor Zurowski]

Hi Everyone:

Unfortunately, closing the staging repository did not succeed and was
aborted with the following error message:

"Missing MD5: 
'/org/apache/camel/camel-optaplanner-starter/2.18.0/camel-optaplanner-starter-2.18.0.pom.md5'"

It seems that something went wrong during the upload to Nexus.  I will
restart the release process and see if it solves the issue.

Thanks,
Gregor


On Tue, Oct 4, 2016 at 9:06 PM, Gregor Zurowski
 wrote:
> Hi Everyone:
>
> I was finally able to create the release without any timeout errors
> and I am currently closing the staging repository.  I will send out
> the vote for the release candidate shortly.
>
> Thanks,
> Gregor
>
>
> On Tue, Oct 4, 2016 at 9:03 AM, Gregor Zurowski
>  wrote:
>> Hi Everyone:
>>
>> Unfortunately the second attempt to release the 2.18.0 RC failed close
>> towards the end of the build process due to connectivity issues with
>> the Apache repository server.  I have just started the release process
>> once again and will post updates to this thread.
>>
>> Thanks,
>> Gregor
>>
>>
>> On Mon, Oct 3, 2016 at 9:35 PM, Claus Ibsen  wrote:
>>> Hi
>>>
>>> Gregor is currently working on the 2.18.0 RC, but there was a
>>> network/timeout issue yesterday, so he has to restart again, which he
>>> is doing today.
>>>
>>> The release is still in the works, so please don't do major
>>> refactorings on the master branch ;)
>>>
>>>
>>> On Sun, Aug 28, 2016 at 5:28 AM, Claus Ibsen  wrote:
 Hi

 Hope everybody had good summer vacation. I had my vacation in parts
 and have next week as PTO.

 We should get started to close down on the upcoming Camel 2.18 release.


 There is some outstanding work (in no particular order)

 1)
 Finish the spring boot stuff with the starter components.
 Nicola comes back from PTO and will work on this.

 2)
 rest-dsl to support calling REST services. I am working on this and
 have some outstanding work still around binding and other
 improvements.

 3)
 Tidy up the log4j v2 upgrade. Some of the examples do not start with
 the jetty plugin.

 4)
 Migrate the last wiki pages to adoc files. There is not so many pages
 left and you can find a report when running camel-catalog build that
 output what is missing.

 This will help us with a base-line for maintaining the documentation
 going forward in the source code adoc files instead of wiki, and we
 can then generate a new website and documentation for the following
 release (2.19 or 3.0) etc. But this is a discussion we should IMHO
 take post 2.18.

 5)
 camel-test-karaf module. This module is in the works but could use
 some review and finishing so its easier to use for end users.

 Notice the existing camel-test-blueprint is still favored for doing
 unit tests which you can run fast and easily debug. The new
 camel-test-karaf is for running integration tests in a running karaf
 instance.

 6)
 We should look at the JIRA tickets that are assigned to 2.18.0 and try
 to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
 releases.

 7)
 Keep an eye on the CI server to make sure the tests are green.
 https://builds.apache.org/view/A-D/view/Camel/


 If all goes well then hopefully in 2-3 weeks we are ready to cut the 
 2.18.0 RC.




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

Re: Getting ready for Apache Camel 2.18 Release

[Gregor Zurowski]

Hi Everyone:

I was finally able to create the release without any timeout errors
and I am currently closing the staging repository.  I will send out
the vote for the release candidate shortly.

Thanks,
Gregor


On Tue, Oct 4, 2016 at 9:03 AM, Gregor Zurowski
 wrote:
> Hi Everyone:
>
> Unfortunately the second attempt to release the 2.18.0 RC failed close
> towards the end of the build process due to connectivity issues with
> the Apache repository server.  I have just started the release process
> once again and will post updates to this thread.
>
> Thanks,
> Gregor
>
>
> On Mon, Oct 3, 2016 at 9:35 PM, Claus Ibsen  wrote:
>> Hi
>>
>> Gregor is currently working on the 2.18.0 RC, but there was a
>> network/timeout issue yesterday, so he has to restart again, which he
>> is doing today.
>>
>> The release is still in the works, so please don't do major
>> refactorings on the master branch ;)
>>
>>
>> On Sun, Aug 28, 2016 at 5:28 AM, Claus Ibsen  wrote:
>>> Hi
>>>
>>> Hope everybody had good summer vacation. I had my vacation in parts
>>> and have next week as PTO.
>>>
>>> We should get started to close down on the upcoming Camel 2.18 release.
>>>
>>>
>>> There is some outstanding work (in no particular order)
>>>
>>> 1)
>>> Finish the spring boot stuff with the starter components.
>>> Nicola comes back from PTO and will work on this.
>>>
>>> 2)
>>> rest-dsl to support calling REST services. I am working on this and
>>> have some outstanding work still around binding and other
>>> improvements.
>>>
>>> 3)
>>> Tidy up the log4j v2 upgrade. Some of the examples do not start with
>>> the jetty plugin.
>>>
>>> 4)
>>> Migrate the last wiki pages to adoc files. There is not so many pages
>>> left and you can find a report when running camel-catalog build that
>>> output what is missing.
>>>
>>> This will help us with a base-line for maintaining the documentation
>>> going forward in the source code adoc files instead of wiki, and we
>>> can then generate a new website and documentation for the following
>>> release (2.19 or 3.0) etc. But this is a discussion we should IMHO
>>> take post 2.18.
>>>
>>> 5)
>>> camel-test-karaf module. This module is in the works but could use
>>> some review and finishing so its easier to use for end users.
>>>
>>> Notice the existing camel-test-blueprint is still favored for doing
>>> unit tests which you can run fast and easily debug. The new
>>> camel-test-karaf is for running integration tests in a running karaf
>>> instance.
>>>
>>> 6)
>>> We should look at the JIRA tickets that are assigned to 2.18.0 and try
>>> to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
>>> releases.
>>>
>>> 7)
>>> Keep an eye on the CI server to make sure the tests are green.
>>> https://builds.apache.org/view/A-D/view/Camel/
>>>
>>>
>>> If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 
>>> RC.
>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>> --
>> Claus Ibsen
>> -
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2

Re: Getting ready for Apache Camel 2.18 Release

[Gregor Zurowski]

Hi Everyone:

Unfortunately the second attempt to release the 2.18.0 RC failed close
towards the end of the build process due to connectivity issues with
the Apache repository server.  I have just started the release process
once again and will post updates to this thread.

Thanks,
Gregor


On Mon, Oct 3, 2016 at 9:35 PM, Claus Ibsen  wrote:
> Hi
>
> Gregor is currently working on the 2.18.0 RC, but there was a
> network/timeout issue yesterday, so he has to restart again, which he
> is doing today.
>
> The release is still in the works, so please don't do major
> refactorings on the master branch ;)
>
>
> On Sun, Aug 28, 2016 at 5:28 AM, Claus Ibsen  wrote:
>> Hi
>>
>> Hope everybody had good summer vacation. I had my vacation in parts
>> and have next week as PTO.
>>
>> We should get started to close down on the upcoming Camel 2.18 release.
>>
>>
>> There is some outstanding work (in no particular order)
>>
>> 1)
>> Finish the spring boot stuff with the starter components.
>> Nicola comes back from PTO and will work on this.
>>
>> 2)
>> rest-dsl to support calling REST services. I am working on this and
>> have some outstanding work still around binding and other
>> improvements.
>>
>> 3)
>> Tidy up the log4j v2 upgrade. Some of the examples do not start with
>> the jetty plugin.
>>
>> 4)
>> Migrate the last wiki pages to adoc files. There is not so many pages
>> left and you can find a report when running camel-catalog build that
>> output what is missing.
>>
>> This will help us with a base-line for maintaining the documentation
>> going forward in the source code adoc files instead of wiki, and we
>> can then generate a new website and documentation for the following
>> release (2.19 or 3.0) etc. But this is a discussion we should IMHO
>> take post 2.18.
>>
>> 5)
>> camel-test-karaf module. This module is in the works but could use
>> some review and finishing so its easier to use for end users.
>>
>> Notice the existing camel-test-blueprint is still favored for doing
>> unit tests which you can run fast and easily debug. The new
>> camel-test-karaf is for running integration tests in a running karaf
>> instance.
>>
>> 6)
>> We should look at the JIRA tickets that are assigned to 2.18.0 and try
>> to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
>> releases.
>>
>> 7)
>> Keep an eye on the CI server to make sure the tests are green.
>> https://builds.apache.org/view/A-D/view/Camel/
>>
>>
>> If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 
>> RC.
>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

The job completed and there was 2 flaky tests about camel-quartz
(deprecated) which can happen from time to time.

We are looking good for cutting the RC.


On Sat, Oct 1, 2016 at 1:32 PM, Claus Ibsen  wrote:
> Hi
>
> The previous CI job was aborted after 5h30m because it was configured
> to timeout after that duration, but it was still going, it was running
> the itests at the time.
>
> So I have bumped up the timeout value and kicked off a new one
> https://builds.apache.org/view/A-D/view/Camel/job/Camel.trunk.fulltest.java8/966/
>
> Its currently running but seems to run on a slower box, so it hasn't got so 
> far.
>
> On Fri, Sep 30, 2016 at 4:32 PM, Claus Ibsen  wrote:
>> Hi
>>
>> I kicked off a CI test
>> https://builds.apache.org/view/A-D/view/Camel/job/Camel.trunk.fulltest.java8/965/
>>
>> The CI server had a bit of issues of late with weird hudson/jenkins
>> errors and some of them dont have so much memory, so they can't run
>> the full test suite.
>>
>> Lets keep an eye on this one, and see if it reports any mistakes.
>>
>> Tests locally have been fine of late for me, but you never know.
>>
>>
>>
>>
>>
>> On Fri, Sep 30, 2016 at 3:53 PM, Andrea Cosentino
>>  wrote:
>>> I finished the alignment.
>>>
>>> I guess we are ready to cut the release.
>>>
>>> Thoughts? Last minute addition? :-)
>>>
>>> --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 29, 2016 5:04 PM, Andrea Cosentino 
>>>  wrote:
>>> And obviously, thanks Gregor!
>>> --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 29, 2016 4:59 PM, Andrea Cosentino 
>>>  wrote:
>>> I'll try to align everything during tomorrow.
>>>
>>> So I guess It will be ok.
>>> --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 29, 2016 4:57 PM, Gregor Zurowski 
>>>  wrote:
>>> Hi Claus,
>>>
>>> I will be able to create a release candidate for 2.18 this weekend, so
>>> we could start the vote around Sunday/Monday.  Does that work for
>>> everyone?
>>>
>>> Thanks,
>>> Gregor
>>>
>>>
>>> On Thu, Sep 29, 2016 at 3:17 PM, Claus Ibsen  wrote:
 Hi Gregor

 When Andreas have updated the SMX bundles tomorrow, then we should be
 ready to start cutting a RC.

 I wonder when you have time in your calendar to cut a release?



 On Wed, Sep 28, 2016 at 9:18 AM, Andrea Cosentino
  wrote:
> Hello Claus,
>
> We are on vote now. Hopefully we should be able to have the bundles on 
> Friday.
>  --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Wednesday, September 28, 2016 9:17 AM, Claus Ibsen 
>  wrote:
> Hi Andrea
>
> How is it going with the SMX bundle release?
>
>
>
> On Fri, Sep 23, 2016 at 4:43 PM, Andrea Cosentino
>  wrote:
>> During the weekend JB will cut release for SMX bundles.
>>
>> So we should be able to align karaf features and be ready to release by 
>> the middle of the next week.
>>  --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
>>  wrote:
>> I physically removed the folders of the starters and I pulled master 
>> aligning to the codebase.
>>
>> This way it should work fine.
>>
>> --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro 
>>  wrote:
>> That Happened also to Andrea yesterday. The cause should be the 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi

The previous CI job was aborted after 5h30m because it was configured
to timeout after that duration, but it was still going, it was running
the itests at the time.

So I have bumped up the timeout value and kicked off a new one
https://builds.apache.org/view/A-D/view/Camel/job/Camel.trunk.fulltest.java8/966/

Its currently running but seems to run on a slower box, so it hasn't got so far.

On Fri, Sep 30, 2016 at 4:32 PM, Claus Ibsen  wrote:
> Hi
>
> I kicked off a CI test
> https://builds.apache.org/view/A-D/view/Camel/job/Camel.trunk.fulltest.java8/965/
>
> The CI server had a bit of issues of late with weird hudson/jenkins
> errors and some of them dont have so much memory, so they can't run
> the full test suite.
>
> Lets keep an eye on this one, and see if it reports any mistakes.
>
> Tests locally have been fine of late for me, but you never know.
>
>
>
>
>
> On Fri, Sep 30, 2016 at 3:53 PM, Andrea Cosentino
>  wrote:
>> I finished the alignment.
>>
>> I guess we are ready to cut the release.
>>
>> Thoughts? Last minute addition? :-)
>>
>> --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Thursday, September 29, 2016 5:04 PM, Andrea Cosentino 
>>  wrote:
>> And obviously, thanks Gregor!
>> --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Thursday, September 29, 2016 4:59 PM, Andrea Cosentino 
>>  wrote:
>> I'll try to align everything during tomorrow.
>>
>> So I guess It will be ok.
>> --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Thursday, September 29, 2016 4:57 PM, Gregor Zurowski 
>>  wrote:
>> Hi Claus,
>>
>> I will be able to create a release candidate for 2.18 this weekend, so
>> we could start the vote around Sunday/Monday.  Does that work for
>> everyone?
>>
>> Thanks,
>> Gregor
>>
>>
>> On Thu, Sep 29, 2016 at 3:17 PM, Claus Ibsen  wrote:
>>> Hi Gregor
>>>
>>> When Andreas have updated the SMX bundles tomorrow, then we should be
>>> ready to start cutting a RC.
>>>
>>> I wonder when you have time in your calendar to cut a release?
>>>
>>>
>>>
>>> On Wed, Sep 28, 2016 at 9:18 AM, Andrea Cosentino
>>>  wrote:
 Hello Claus,

 We are on vote now. Hopefully we should be able to have the bundles on 
 Friday.
  --
 Andrea Cosentino
 --
 Apache Camel PMC Member
 Apache Karaf Committer
 Apache Servicemix Committer
 Email: ancosen1...@yahoo.com
 Twitter: @oscerd2
 Github: oscerd



 On Wednesday, September 28, 2016 9:17 AM, Claus Ibsen 
  wrote:
 Hi Andrea

 How is it going with the SMX bundle release?



 On Fri, Sep 23, 2016 at 4:43 PM, Andrea Cosentino
  wrote:
> During the weekend JB will cut release for SMX bundles.
>
> So we should be able to align karaf features and be ready to release by 
> the middle of the next week.
>  --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
>  wrote:
> I physically removed the folders of the starters and I pulled master 
> aligning to the codebase.
>
> This way it should work fine.
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro 
>  wrote:
> That Happened also to Andrea yesterday. The cause should be the blacklist,
> that is hardcoded in the camel-package maven plugin, so you have to 
> rebuild
> the plugin first.
> The plugin does not delete the starters, it is just able to create them.
> They have been deleted from the repo, but probably some git clients leave
> the empty folders, so I pushed right now some changes to improve the
> detection of all required starters.
>
> 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi

I kicked off a CI test
https://builds.apache.org/view/A-D/view/Camel/job/Camel.trunk.fulltest.java8/965/

The CI server had a bit of issues of late with weird hudson/jenkins
errors and some of them dont have so much memory, so they can't run
the full test suite.

Lets keep an eye on this one, and see if it reports any mistakes.

Tests locally have been fine of late for me, but you never know.





On Fri, Sep 30, 2016 at 3:53 PM, Andrea Cosentino
 wrote:
> I finished the alignment.
>
> I guess we are ready to cut the release.
>
> Thoughts? Last minute addition? :-)
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Thursday, September 29, 2016 5:04 PM, Andrea Cosentino 
>  wrote:
> And obviously, thanks Gregor!
> --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Thursday, September 29, 2016 4:59 PM, Andrea Cosentino 
>  wrote:
> I'll try to align everything during tomorrow.
>
> So I guess It will be ok.
> --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Thursday, September 29, 2016 4:57 PM, Gregor Zurowski 
>  wrote:
> Hi Claus,
>
> I will be able to create a release candidate for 2.18 this weekend, so
> we could start the vote around Sunday/Monday.  Does that work for
> everyone?
>
> Thanks,
> Gregor
>
>
> On Thu, Sep 29, 2016 at 3:17 PM, Claus Ibsen  wrote:
>> Hi Gregor
>>
>> When Andreas have updated the SMX bundles tomorrow, then we should be
>> ready to start cutting a RC.
>>
>> I wonder when you have time in your calendar to cut a release?
>>
>>
>>
>> On Wed, Sep 28, 2016 at 9:18 AM, Andrea Cosentino
>>  wrote:
>>> Hello Claus,
>>>
>>> We are on vote now. Hopefully we should be able to have the bundles on 
>>> Friday.
>>>  --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Wednesday, September 28, 2016 9:17 AM, Claus Ibsen 
>>>  wrote:
>>> Hi Andrea
>>>
>>> How is it going with the SMX bundle release?
>>>
>>>
>>>
>>> On Fri, Sep 23, 2016 at 4:43 PM, Andrea Cosentino
>>>  wrote:
 During the weekend JB will cut release for SMX bundles.

 So we should be able to align karaf features and be ready to release by 
 the middle of the next week.
  --
 Andrea Cosentino
 --
 Apache Camel PMC Member
 Apache Karaf Committer
 Apache Servicemix Committer
 Email: ancosen1...@yahoo.com
 Twitter: @oscerd2
 Github: oscerd



 On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
  wrote:
 I physically removed the folders of the starters and I pulled master 
 aligning to the codebase.

 This way it should work fine.

 --
 Andrea Cosentino
 --
 Apache Camel PMC Member
 Apache Karaf Committer
 Apache Servicemix Committer
 Email: ancosen1...@yahoo.com
 Twitter: @oscerd2
 Github: oscerd



 On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro 
  wrote:
 That Happened also to Andrea yesterday. The cause should be the blacklist,
 that is hardcoded in the camel-package maven plugin, so you have to rebuild
 the plugin first.
 The plugin does not delete the starters, it is just able to create them.
 They have been deleted from the repo, but probably some git clients leave
 the empty folders, so I pushed right now some changes to improve the
 detection of all required starters.

 But once they are created by chance, you have to delete them manually.
 Deleting them and doing a full rebuild should solve the problem, because
 the plugin is at the top of the reactor list. Just a full rebuild after the
 update should be sufficient for the others (I hope).

 I just did a check with latest code from Apache master.


 On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:

> Hi Nicola
>
> When I build the latest code then some -starter modules are generated
> for modules that ought to be blacklisted
>
> components-starter/camel-ejb-starter/
> 

Re: Getting ready for Apache Camel 2.18 Release

[Andrea Cosentino]

I finished the alignment.

I guess we are ready to cut the release.

Thoughts? Last minute addition? :-)

--
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, September 29, 2016 5:04 PM, Andrea Cosentino 
 wrote:
And obviously, thanks Gregor!
--
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, September 29, 2016 4:59 PM, Andrea Cosentino 
 wrote:
I'll try to align everything during tomorrow.

So I guess It will be ok.
--
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, September 29, 2016 4:57 PM, Gregor Zurowski 
 wrote:
Hi Claus,

I will be able to create a release candidate for 2.18 this weekend, so
we could start the vote around Sunday/Monday.  Does that work for
everyone?

Thanks,
Gregor


On Thu, Sep 29, 2016 at 3:17 PM, Claus Ibsen  wrote:
> Hi Gregor
>
> When Andreas have updated the SMX bundles tomorrow, then we should be
> ready to start cutting a RC.
>
> I wonder when you have time in your calendar to cut a release?
>
>
>
> On Wed, Sep 28, 2016 at 9:18 AM, Andrea Cosentino
>  wrote:
>> Hello Claus,
>>
>> We are on vote now. Hopefully we should be able to have the bundles on 
>> Friday.
>>  --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Wednesday, September 28, 2016 9:17 AM, Claus Ibsen 
>>  wrote:
>> Hi Andrea
>>
>> How is it going with the SMX bundle release?
>>
>>
>>
>> On Fri, Sep 23, 2016 at 4:43 PM, Andrea Cosentino
>>  wrote:
>>> During the weekend JB will cut release for SMX bundles.
>>>
>>> So we should be able to align karaf features and be ready to release by the 
>>> middle of the next week.
>>>  --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
>>>  wrote:
>>> I physically removed the folders of the starters and I pulled master 
>>> aligning to the codebase.
>>>
>>> This way it should work fine.
>>>
>>> --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro 
>>>  wrote:
>>> That Happened also to Andrea yesterday. The cause should be the blacklist,
>>> that is hardcoded in the camel-package maven plugin, so you have to rebuild
>>> the plugin first.
>>> The plugin does not delete the starters, it is just able to create them.
>>> They have been deleted from the repo, but probably some git clients leave
>>> the empty folders, so I pushed right now some changes to improve the
>>> detection of all required starters.
>>>
>>> But once they are created by chance, you have to delete them manually.
>>> Deleting them and doing a full rebuild should solve the problem, because
>>> the plugin is at the top of the reactor list. Just a full rebuild after the
>>> update should be sufficient for the others (I hope).
>>>
>>> I just did a check with latest code from Apache master.
>>>
>>>
>>> On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:
>>>
 Hi Nicola

 When I build the latest code then some -starter modules are generated
 for modules that ought to be blacklisted

 components-starter/camel-ejb-starter/
 components-starter/camel-ibatis-starter/
 components-starter/camel-jclouds-starter/
 components-starter/camel-quartz-starter/

 On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro 
 wrote:
 > 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 

Re: Getting ready for Apache Camel 2.18 Release

[Andrea Cosentino]

And obviously, thanks Gregor!
 --
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, September 29, 2016 4:59 PM, Andrea Cosentino 
 wrote:
And obviously, thanks Gregor!
--
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, September 29, 2016 4:59 PM, Andrea Cosentino 
 wrote:
I'll try to align everything during tomorrow.

So I guess It will be ok.
--
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, September 29, 2016 4:57 PM, Gregor Zurowski 
 wrote:
Hi Claus,

I will be able to create a release candidate for 2.18 this weekend, so
we could start the vote around Sunday/Monday.  Does that work for
everyone?

Thanks,
Gregor


On Thu, Sep 29, 2016 at 3:17 PM, Claus Ibsen  wrote:
> Hi Gregor
>
> When Andreas have updated the SMX bundles tomorrow, then we should be
> ready to start cutting a RC.
>
> I wonder when you have time in your calendar to cut a release?
>
>
>
> On Wed, Sep 28, 2016 at 9:18 AM, Andrea Cosentino
>  wrote:
>> Hello Claus,
>>
>> We are on vote now. Hopefully we should be able to have the bundles on 
>> Friday.
>>  --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Wednesday, September 28, 2016 9:17 AM, Claus Ibsen 
>>  wrote:
>> Hi Andrea
>>
>> How is it going with the SMX bundle release?
>>
>>
>>
>> On Fri, Sep 23, 2016 at 4:43 PM, Andrea Cosentino
>>  wrote:
>>> During the weekend JB will cut release for SMX bundles.
>>>
>>> So we should be able to align karaf features and be ready to release by the 
>>> middle of the next week.
>>>  --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
>>>  wrote:
>>> I physically removed the folders of the starters and I pulled master 
>>> aligning to the codebase.
>>>
>>> This way it should work fine.
>>>
>>> --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro 
>>>  wrote:
>>> That Happened also to Andrea yesterday. The cause should be the blacklist,
>>> that is hardcoded in the camel-package maven plugin, so you have to rebuild
>>> the plugin first.
>>> The plugin does not delete the starters, it is just able to create them.
>>> They have been deleted from the repo, but probably some git clients leave
>>> the empty folders, so I pushed right now some changes to improve the
>>> detection of all required starters.
>>>
>>> But once they are created by chance, you have to delete them manually.
>>> Deleting them and doing a full rebuild should solve the problem, because
>>> the plugin is at the top of the reactor list. Just a full rebuild after the
>>> update should be sufficient for the others (I hope).
>>>
>>> I just did a check with latest code from Apache master.
>>>
>>>
>>> On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:
>>>
 Hi Nicola

 When I build the latest code then some -starter modules are generated
 for modules that ought to be blacklisted

 components-starter/camel-ejb-starter/
 components-starter/camel-ibatis-starter/
 components-starter/camel-jclouds-starter/
 components-starter/camel-quartz-starter/

 On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro 
 wrote:
 > 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 

Re: Getting ready for Apache Camel 2.18 Release

[Andrea Cosentino]

I'll try to align everything during tomorrow.

So I guess It will be ok.
 --
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, September 29, 2016 4:57 PM, Gregor Zurowski 
 wrote:
Hi Claus,

I will be able to create a release candidate for 2.18 this weekend, so
we could start the vote around Sunday/Monday.  Does that work for
everyone?

Thanks,
Gregor


On Thu, Sep 29, 2016 at 3:17 PM, Claus Ibsen  wrote:
> Hi Gregor
>
> When Andreas have updated the SMX bundles tomorrow, then we should be
> ready to start cutting a RC.
>
> I wonder when you have time in your calendar to cut a release?
>
>
>
> On Wed, Sep 28, 2016 at 9:18 AM, Andrea Cosentino
>  wrote:
>> Hello Claus,
>>
>> We are on vote now. Hopefully we should be able to have the bundles on 
>> Friday.
>>  --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Wednesday, September 28, 2016 9:17 AM, Claus Ibsen 
>>  wrote:
>> Hi Andrea
>>
>> How is it going with the SMX bundle release?
>>
>>
>>
>> On Fri, Sep 23, 2016 at 4:43 PM, Andrea Cosentino
>>  wrote:
>>> During the weekend JB will cut release for SMX bundles.
>>>
>>> So we should be able to align karaf features and be ready to release by the 
>>> middle of the next week.
>>>  --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
>>>  wrote:
>>> I physically removed the folders of the starters and I pulled master 
>>> aligning to the codebase.
>>>
>>> This way it should work fine.
>>>
>>> --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro 
>>>  wrote:
>>> That Happened also to Andrea yesterday. The cause should be the blacklist,
>>> that is hardcoded in the camel-package maven plugin, so you have to rebuild
>>> the plugin first.
>>> The plugin does not delete the starters, it is just able to create them.
>>> They have been deleted from the repo, but probably some git clients leave
>>> the empty folders, so I pushed right now some changes to improve the
>>> detection of all required starters.
>>>
>>> But once they are created by chance, you have to delete them manually.
>>> Deleting them and doing a full rebuild should solve the problem, because
>>> the plugin is at the top of the reactor list. Just a full rebuild after the
>>> update should be sufficient for the others (I hope).
>>>
>>> I just did a check with latest code from Apache master.
>>>
>>>
>>> On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:
>>>
 Hi Nicola

 When I build the latest code then some -starter modules are generated
 for modules that ought to be blacklisted

 components-starter/camel-ejb-starter/
 components-starter/camel-ibatis-starter/
 components-starter/camel-jclouds-starter/
 components-starter/camel-quartz-starter/

 On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro 
 wrote:
 > 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,
 

Re: Getting ready for Apache Camel 2.18 Release

[Gregor Zurowski]

Hi Claus,

I will be able to create a release candidate for 2.18 this weekend, so
we could start the vote around Sunday/Monday.  Does that work for
everyone?

Thanks,
Gregor


On Thu, Sep 29, 2016 at 3:17 PM, Claus Ibsen  wrote:
> Hi Gregor
>
> When Andreas have updated the SMX bundles tomorrow, then we should be
> ready to start cutting a RC.
>
> I wonder when you have time in your calendar to cut a release?
>
>
>
> On Wed, Sep 28, 2016 at 9:18 AM, Andrea Cosentino
>  wrote:
>> Hello Claus,
>>
>> We are on vote now. Hopefully we should be able to have the bundles on 
>> Friday.
>>  --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Wednesday, September 28, 2016 9:17 AM, Claus Ibsen 
>>  wrote:
>> Hi Andrea
>>
>> How is it going with the SMX bundle release?
>>
>>
>>
>> On Fri, Sep 23, 2016 at 4:43 PM, Andrea Cosentino
>>  wrote:
>>> During the weekend JB will cut release for SMX bundles.
>>>
>>> So we should be able to align karaf features and be ready to release by the 
>>> middle of the next week.
>>>  --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
>>>  wrote:
>>> I physically removed the folders of the starters and I pulled master 
>>> aligning to the codebase.
>>>
>>> This way it should work fine.
>>>
>>> --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro 
>>>  wrote:
>>> That Happened also to Andrea yesterday. The cause should be the blacklist,
>>> that is hardcoded in the camel-package maven plugin, so you have to rebuild
>>> the plugin first.
>>> The plugin does not delete the starters, it is just able to create them.
>>> They have been deleted from the repo, but probably some git clients leave
>>> the empty folders, so I pushed right now some changes to improve the
>>> detection of all required starters.
>>>
>>> But once they are created by chance, you have to delete them manually.
>>> Deleting them and doing a full rebuild should solve the problem, because
>>> the plugin is at the top of the reactor list. Just a full rebuild after the
>>> update should be sufficient for the others (I hope).
>>>
>>> I just did a check with latest code from Apache master.
>>>
>>>
>>> On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:
>>>
 Hi Nicola

 When I build the latest code then some -starter modules are generated
 for modules that ought to be blacklisted

 components-starter/camel-ejb-starter/
 components-starter/camel-ibatis-starter/
 components-starter/camel-jclouds-starter/
 components-starter/camel-quartz-starter/

 On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro 
 wrote:
 > 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
 >> > 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi Gregor

When Andreas have updated the SMX bundles tomorrow, then we should be
ready to start cutting a RC.

I wonder when you have time in your calendar to cut a release?



On Wed, Sep 28, 2016 at 9:18 AM, Andrea Cosentino
 wrote:
> Hello Claus,
>
> We are on vote now. Hopefully we should be able to have the bundles on Friday.
>  --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Wednesday, September 28, 2016 9:17 AM, Claus Ibsen  
> wrote:
> Hi Andrea
>
> How is it going with the SMX bundle release?
>
>
>
> On Fri, Sep 23, 2016 at 4:43 PM, Andrea Cosentino
>  wrote:
>> During the weekend JB will cut release for SMX bundles.
>>
>> So we should be able to align karaf features and be ready to release by the 
>> middle of the next week.
>>  --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
>>  wrote:
>> I physically removed the folders of the starters and I pulled master 
>> aligning to the codebase.
>>
>> This way it should work fine.
>>
>> --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro 
>>  wrote:
>> That Happened also to Andrea yesterday. The cause should be the blacklist,
>> that is hardcoded in the camel-package maven plugin, so you have to rebuild
>> the plugin first.
>> The plugin does not delete the starters, it is just able to create them.
>> They have been deleted from the repo, but probably some git clients leave
>> the empty folders, so I pushed right now some changes to improve the
>> detection of all required starters.
>>
>> But once they are created by chance, you have to delete them manually.
>> Deleting them and doing a full rebuild should solve the problem, because
>> the plugin is at the top of the reactor list. Just a full rebuild after the
>> update should be sufficient for the others (I hope).
>>
>> I just did a check with latest code from Apache master.
>>
>>
>> On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:
>>
>>> Hi Nicola
>>>
>>> When I build the latest code then some -starter modules are generated
>>> for modules that ought to be blacklisted
>>>
>>> components-starter/camel-ejb-starter/
>>> components-starter/camel-ibatis-starter/
>>> components-starter/camel-jclouds-starter/
>>> components-starter/camel-quartz-starter/
>>>
>>> On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro 
>>> wrote:
>>> > 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

Re: Getting ready for Apache Camel 2.18 Release

[Andrea Cosentino]

Hello Claus,

We are on vote now. Hopefully we should be able to have the bundles on Friday.
 --
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Wednesday, September 28, 2016 9:17 AM, Claus Ibsen  
wrote:
Hi Andrea

How is it going with the SMX bundle release?



On Fri, Sep 23, 2016 at 4:43 PM, Andrea Cosentino
 wrote:
> During the weekend JB will cut release for SMX bundles.
>
> So we should be able to align karaf features and be ready to release by the 
> middle of the next week.
>  --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
>  wrote:
> I physically removed the folders of the starters and I pulled master aligning 
> to the codebase.
>
> This way it should work fine.
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro 
>  wrote:
> That Happened also to Andrea yesterday. The cause should be the blacklist,
> that is hardcoded in the camel-package maven plugin, so you have to rebuild
> the plugin first.
> The plugin does not delete the starters, it is just able to create them.
> They have been deleted from the repo, but probably some git clients leave
> the empty folders, so I pushed right now some changes to improve the
> detection of all required starters.
>
> But once they are created by chance, you have to delete them manually.
> Deleting them and doing a full rebuild should solve the problem, because
> the plugin is at the top of the reactor list. Just a full rebuild after the
> update should be sufficient for the others (I hope).
>
> I just did a check with latest code from Apache master.
>
>
> On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:
>
>> Hi Nicola
>>
>> When I build the latest code then some -starter modules are generated
>> for modules that ought to be blacklisted
>>
>> components-starter/camel-ejb-starter/
>> components-starter/camel-ibatis-starter/
>> components-starter/camel-jclouds-starter/
>> components-starter/camel-quartz-starter/
>>
>> On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro 
>> wrote:
>> > 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.
>> >> 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi Andrea

How is it going with the SMX bundle release?



On Fri, Sep 23, 2016 at 4:43 PM, Andrea Cosentino
 wrote:
> During the weekend JB will cut release for SMX bundles.
>
> So we should be able to align karaf features and be ready to release by the 
> middle of the next week.
>  --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
>  wrote:
> I physically removed the folders of the starters and I pulled master aligning 
> to the codebase.
>
> This way it should work fine.
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro 
>  wrote:
> That Happened also to Andrea yesterday. The cause should be the blacklist,
> that is hardcoded in the camel-package maven plugin, so you have to rebuild
> the plugin first.
> The plugin does not delete the starters, it is just able to create them.
> They have been deleted from the repo, but probably some git clients leave
> the empty folders, so I pushed right now some changes to improve the
> detection of all required starters.
>
> But once they are created by chance, you have to delete them manually.
> Deleting them and doing a full rebuild should solve the problem, because
> the plugin is at the top of the reactor list. Just a full rebuild after the
> update should be sufficient for the others (I hope).
>
> I just did a check with latest code from Apache master.
>
>
> On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:
>
>> Hi Nicola
>>
>> When I build the latest code then some -starter modules are generated
>> for modules that ought to be blacklisted
>>
>> components-starter/camel-ejb-starter/
>> components-starter/camel-ibatis-starter/
>> components-starter/camel-jclouds-starter/
>> components-starter/camel-quartz-starter/
>>
>> On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro 
>> wrote:
>> > 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.
>> >> >>
>> >> >>
>> >> >>
>> 

Re: Getting ready for Apache Camel 2.18 Release

[fabryprog]

for this problem open this issue:
https://issues.apache.org/jira/browse/CAMEL-10349



--
View this message in context: 
http://camel.465427.n5.nabble.com/Getting-ready-for-Apache-Camel-2-18-Release-tp5786942p5788128.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Getting ready for Apache Camel 2.18 Release

[fabryprog]

Hello,

I may have found a bug derived from 2.18

Before 2.18, i can specified an header like:


 [{"firstField": "firstValue",
"secondField":"secondValue"}]


In my bean, *myHeader* will be cast to
*ArrayList>*

After 2.18 upgrade i had an error

*'java.lang.ClassCastException: jdk.nashorn.api.scripting.ScriptObjectMirror
cannot be cast to java.util.List'*

Can you help me? Is it a camel bug or an jdk8 issue?



--
View this message in context: 
http://camel.465427.n5.nabble.com/Getting-ready-for-Apache-Camel-2-18-Release-tp5786942p5788108.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Getting ready for Apache Camel 2.18 Release

[Andrea Cosentino]

During the weekend JB will cut release for SMX bundles.

So we should be able to align karaf features and be ready to release by the 
middle of the next week.
 --
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, September 22, 2016 9:36 AM, Andrea Cosentino 
 wrote:
I physically removed the folders of the starters and I pulled master aligning 
to the codebase.

This way it should work fine.

--
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro  
wrote:
That Happened also to Andrea yesterday. The cause should be the blacklist,
that is hardcoded in the camel-package maven plugin, so you have to rebuild
the plugin first.
The plugin does not delete the starters, it is just able to create them.
They have been deleted from the repo, but probably some git clients leave
the empty folders, so I pushed right now some changes to improve the
detection of all required starters.

But once they are created by chance, you have to delete them manually.
Deleting them and doing a full rebuild should solve the problem, because
the plugin is at the top of the reactor list. Just a full rebuild after the
update should be sufficient for the others (I hope).

I just did a check with latest code from Apache master.


On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:

> Hi Nicola
>
> When I build the latest code then some -starter modules are generated
> for modules that ought to be blacklisted
>
> components-starter/camel-ejb-starter/
> components-starter/camel-ibatis-starter/
> components-starter/camel-jclouds-starter/
> components-starter/camel-quartz-starter/
>
> On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro 
> wrote:
> > 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 <
> ni.ferr...@gmail.com>
> >> >> 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:
> >> 

Re: Getting ready for Apache Camel 2.18 Release

[Andrea Cosentino]

I physically removed the folders of the starters and I pulled master aligning 
to the codebase.

This way it should work fine.
 
--
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, September 22, 2016 9:26 AM, Nicola Ferraro  
wrote:
That Happened also to Andrea yesterday. The cause should be the blacklist,
that is hardcoded in the camel-package maven plugin, so you have to rebuild
the plugin first.
The plugin does not delete the starters, it is just able to create them.
They have been deleted from the repo, but probably some git clients leave
the empty folders, so I pushed right now some changes to improve the
detection of all required starters.

But once they are created by chance, you have to delete them manually.
Deleting them and doing a full rebuild should solve the problem, because
the plugin is at the top of the reactor list. Just a full rebuild after the
update should be sufficient for the others (I hope).

I just did a check with latest code from Apache master.


On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:

> Hi Nicola
>
> When I build the latest code then some -starter modules are generated
> for modules that ought to be blacklisted
>
> components-starter/camel-ejb-starter/
> components-starter/camel-ibatis-starter/
> components-starter/camel-jclouds-starter/
> components-starter/camel-quartz-starter/
>
> On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro 
> wrote:
> > 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 <
> ni.ferr...@gmail.com>
> >> >> 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 

Re: Getting ready for Apache Camel 2.18 Release

[Nicola Ferraro]

That Happened also to Andrea yesterday. The cause should be the blacklist,
that is hardcoded in the camel-package maven plugin, so you have to rebuild
the plugin first.
The plugin does not delete the starters, it is just able to create them.
They have been deleted from the repo, but probably some git clients leave
the empty folders, so I pushed right now some changes to improve the
detection of all required starters.

But once they are created by chance, you have to delete them manually.
Deleting them and doing a full rebuild should solve the problem, because
the plugin is at the top of the reactor list. Just a full rebuild after the
update should be sufficient for the others (I hope).

I just did a check with latest code from Apache master.


On Thu, Sep 22, 2016 at 8:35 AM, Claus Ibsen  wrote:

> Hi Nicola
>
> When I build the latest code then some -starter modules are generated
> for modules that ought to be blacklisted
>
> components-starter/camel-ejb-starter/
> components-starter/camel-ibatis-starter/
> components-starter/camel-jclouds-starter/
> components-starter/camel-quartz-starter/
>
> On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro 
> wrote:
> > 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 <
> ni.ferr...@gmail.com>
> >> >> 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
> >> >> > 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi Nicola

When I build the latest code then some -starter modules are generated
for modules that ought to be blacklisted

components-starter/camel-ejb-starter/
components-starter/camel-ibatis-starter/
components-starter/camel-jclouds-starter/
components-starter/camel-quartz-starter/

On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro  wrote:
> 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 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi Jean

Thanks let us know how the SMX bundles release are going, so Andreas
can update the karaf features and run the tests to ensure the upgrades
work for us.

On Wed, Sep 21, 2016 at 12:44 PM, Jean-Baptiste Onofré  
wrote:
> Hi guys
>
> I'm starting the SMX bundles release now.
>
> Regards
> JB
>
>
>
> On Sep 21, 2016, 03:34, at 03:34, Andrea Cosentino 
>  wrote:
>>Not sure, it depends from Jean Baptiste Onofrè.
>> --
>>Andrea Cosentino
>>--
>>Apache Camel PMC Member
>>Apache Karaf Committer
>>Apache Servicemix Committer
>>Email: ancosen1...@yahoo.com
>>Twitter: @oscerd2
>>Github: oscerd
>>
>>
>>
>>On Wednesday, September 21, 2016 12:17 PM, Claus Ibsen
>> wrote:
>>Can you speedup those SMX bundle release.
>>
>>We dont want to hold back Camel release.
>>There is people eager waiting for the 2.18.0 release of Camel.
>>
>>
>>On Wed, Sep 21, 2016 at 11:51 AM, Andrea Cosentino
>> wrote:
>>> Maybe we should wait for the next SM bundles release.
>>>
>>> We currently have a misalignment in some components.
>>>
>>> It should be by the end of the month.
>>>  --
>>> Andrea Cosentino
>>> --
>>> Apache Camel PMC Member
>>> Apache Karaf Committer
>>> Apache Servicemix Committer
>>> Email: ancosen1...@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>>
>>>
>>>
>>> On Wednesday, September 21, 2016 11:39 AM, Luca Burgazzoli
>> wrote:
>>> Hi Claus,
>>>
>>> upgrade to Saxon 9.7 will be merged today.
>>>
>>>
>>> Luca
>>>
>>>
>>> ---
>>> Luca Burgazzoli
>>>
>>>
>>> On Wed, Sep 21, 2016 at 11:31 AM, Claus Ibsen 
>>wrote:
 Hi

 Just a quick update.

 Nicola has now merged his great work on making Camel and Spring Boot
 work well together with a curated list of -starter components that
 works.

 There is another Camel SB ticket merged about nested configuration
 which we need a bit time to improved/fix etc.

 And also upgrading to SB 1.4.1 which has just been released, but we
 assume its a straightforward upgrade.


 And I think Luca has a bit work on upgrading to Saxon 9.7.

 But those are IMHO the last bigger things we need to finish before
 closing down and cutting a release.


 As usual keep eye on CI server build server
 https://builds.apache.org/view/A-D/view/Camel/

 And the last JIRA tickets for 2.18.0 to be resolved

>>https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.18.0%20AND%20resolution%20%3D%20Unresolved


 The new camel-test-karaf module is ongoing work and in this release
>>as
 a kind of preview where we want community feedback and then continue
 working on this for the next 2.19.0 release to be in good shape.






 On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro
>> wrote:
> 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
>> >>
>> >> 

Re: Getting ready for Apache Camel 2.18 Release

[Jean-Baptiste Onofré]

Hi guys

I'm starting the SMX bundles release now.

Regards
JB



On Sep 21, 2016, 03:34, at 03:34, Andrea Cosentino 
 wrote:
>Not sure, it depends from Jean Baptiste Onofrè.
> --
>Andrea Cosentino 
>--
>Apache Camel PMC Member
>Apache Karaf Committer
>Apache Servicemix Committer
>Email: ancosen1...@yahoo.com
>Twitter: @oscerd2
>Github: oscerd
>
>
>
>On Wednesday, September 21, 2016 12:17 PM, Claus Ibsen
> wrote:
>Can you speedup those SMX bundle release.
>
>We dont want to hold back Camel release.
>There is people eager waiting for the 2.18.0 release of Camel.
>
>
>On Wed, Sep 21, 2016 at 11:51 AM, Andrea Cosentino
> wrote:
>> Maybe we should wait for the next SM bundles release.
>>
>> We currently have a misalignment in some components.
>>
>> It should be by the end of the month.
>>  --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix Committer
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>> On Wednesday, September 21, 2016 11:39 AM, Luca Burgazzoli
> wrote:
>> Hi Claus,
>>
>> upgrade to Saxon 9.7 will be merged today.
>>
>>
>> Luca
>>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Wed, Sep 21, 2016 at 11:31 AM, Claus Ibsen 
>wrote:
>>> Hi
>>>
>>> Just a quick update.
>>>
>>> Nicola has now merged his great work on making Camel and Spring Boot
>>> work well together with a curated list of -starter components that
>>> works.
>>>
>>> There is another Camel SB ticket merged about nested configuration
>>> which we need a bit time to improved/fix etc.
>>>
>>> And also upgrading to SB 1.4.1 which has just been released, but we
>>> assume its a straightforward upgrade.
>>>
>>>
>>> And I think Luca has a bit work on upgrading to Saxon 9.7.
>>>
>>> But those are IMHO the last bigger things we need to finish before
>>> closing down and cutting a release.
>>>
>>>
>>> As usual keep eye on CI server build server
>>> https://builds.apache.org/view/A-D/view/Camel/
>>>
>>> And the last JIRA tickets for 2.18.0 to be resolved
>>>
>https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.18.0%20AND%20resolution%20%3D%20Unresolved
>>>
>>>
>>> The new camel-test-karaf module is ongoing work and in this release
>as
>>> a kind of preview where we want community feedback and then continue
>>> working on this for the next 2.19.0 release to be in good shape.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro
> wrote:
 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 

Re: Getting ready for Apache Camel 2.18 Release

[Andrea Cosentino]

Not sure, it depends from Jean Baptiste Onofrè.
 --
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Wednesday, September 21, 2016 12:17 PM, Claus Ibsen  
wrote:
Can you speedup those SMX bundle release.

We dont want to hold back Camel release.
There is people eager waiting for the 2.18.0 release of Camel.


On Wed, Sep 21, 2016 at 11:51 AM, Andrea Cosentino
 wrote:
> Maybe we should wait for the next SM bundles release.
>
> We currently have a misalignment in some components.
>
> It should be by the end of the month.
>  --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Wednesday, September 21, 2016 11:39 AM, Luca Burgazzoli 
>  wrote:
> Hi Claus,
>
> upgrade to Saxon 9.7 will be merged today.
>
>
> Luca
>
>
> ---
> Luca Burgazzoli
>
>
> On Wed, Sep 21, 2016 at 11:31 AM, Claus Ibsen  wrote:
>> Hi
>>
>> Just a quick update.
>>
>> Nicola has now merged his great work on making Camel and Spring Boot
>> work well together with a curated list of -starter components that
>> works.
>>
>> There is another Camel SB ticket merged about nested configuration
>> which we need a bit time to improved/fix etc.
>>
>> And also upgrading to SB 1.4.1 which has just been released, but we
>> assume its a straightforward upgrade.
>>
>>
>> And I think Luca has a bit work on upgrading to Saxon 9.7.
>>
>> But those are IMHO the last bigger things we need to finish before
>> closing down and cutting a release.
>>
>>
>> As usual keep eye on CI server build server
>> https://builds.apache.org/view/A-D/view/Camel/
>>
>> And the last JIRA tickets for 2.18.0 to be resolved
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.18.0%20AND%20resolution%20%3D%20Unresolved
>>
>>
>> The new camel-test-karaf module is ongoing work and in this release as
>> a kind of preview where we want community feedback and then continue
>> working on this for the next 2.19.0 release to be in good shape.
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro  
>> wrote:
>>> 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 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Can you speedup those SMX bundle release.

We dont want to hold back Camel release.
There is people eager waiting for the 2.18.0 release of Camel.


On Wed, Sep 21, 2016 at 11:51 AM, Andrea Cosentino
 wrote:
> Maybe we should wait for the next SM bundles release.
>
> We currently have a misalignment in some components.
>
> It should be by the end of the month.
>  --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Wednesday, September 21, 2016 11:39 AM, Luca Burgazzoli 
>  wrote:
> Hi Claus,
>
> upgrade to Saxon 9.7 will be merged today.
>
>
> Luca
>
>
> ---
> Luca Burgazzoli
>
>
> On Wed, Sep 21, 2016 at 11:31 AM, Claus Ibsen  wrote:
>> Hi
>>
>> Just a quick update.
>>
>> Nicola has now merged his great work on making Camel and Spring Boot
>> work well together with a curated list of -starter components that
>> works.
>>
>> There is another Camel SB ticket merged about nested configuration
>> which we need a bit time to improved/fix etc.
>>
>> And also upgrading to SB 1.4.1 which has just been released, but we
>> assume its a straightforward upgrade.
>>
>>
>> And I think Luca has a bit work on upgrading to Saxon 9.7.
>>
>> But those are IMHO the last bigger things we need to finish before
>> closing down and cutting a release.
>>
>>
>> As usual keep eye on CI server build server
>> https://builds.apache.org/view/A-D/view/Camel/
>>
>> And the last JIRA tickets for 2.18.0 to be resolved
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.18.0%20AND%20resolution%20%3D%20Unresolved
>>
>>
>> The new camel-test-karaf module is ongoing work and in this release as
>> a kind of preview where we want community feedback and then continue
>> working on this for the next 2.19.0 release to be in good shape.
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro  
>> wrote:
>>> 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 

Re: Getting ready for Apache Camel 2.18 Release

[Luca Burgazzoli]

Hi Claus,

upgrade to Saxon 9.7 will be merged today.


Luca


---
Luca Burgazzoli


On Wed, Sep 21, 2016 at 11:31 AM, Claus Ibsen  wrote:
> Hi
>
> Just a quick update.
>
> Nicola has now merged his great work on making Camel and Spring Boot
> work well together with a curated list of -starter components that
> works.
>
> There is another Camel SB ticket merged about nested configuration
> which we need a bit time to improved/fix etc.
>
> And also upgrading to SB 1.4.1 which has just been released, but we
> assume its a straightforward upgrade.
>
>
> And I think Luca has a bit work on upgrading to Saxon 9.7.
>
> But those are IMHO the last bigger things we need to finish before
> closing down and cutting a release.
>
>
> As usual keep eye on CI server build server
> https://builds.apache.org/view/A-D/view/Camel/
>
> And the last JIRA tickets for 2.18.0 to be resolved
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.18.0%20AND%20resolution%20%3D%20Unresolved
>
>
> The new camel-test-karaf module is ongoing work and in this release as
> a kind of preview where we want community feedback and then continue
> working on this for the next 2.19.0 release to be in good shape.
>
>
>
>
>
>
> On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro  wrote:
>> 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
>>> >> > 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi

Just a quick update.

Nicola has now merged his great work on making Camel and Spring Boot
work well together with a curated list of -starter components that
works.

There is another Camel SB ticket merged about nested configuration
which we need a bit time to improved/fix etc.

And also upgrading to SB 1.4.1 which has just been released, but we
assume its a straightforward upgrade.


And I think Luca has a bit work on upgrading to Saxon 9.7.

But those are IMHO the last bigger things we need to finish before
closing down and cutting a release.


As usual keep eye on CI server build server
https://builds.apache.org/view/A-D/view/Camel/

And the last JIRA tickets for 2.18.0 to be resolved
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.18.0%20AND%20resolution%20%3D%20Unresolved


The new camel-test-karaf module is ongoing work and in this release as
a kind of preview where we want community feedback and then continue
working on this for the next 2.19.0 release to be in good shape.






On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro  wrote:
> 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 

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 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

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?
>

That is a really good idea.

I think we should try to make Spring Boot the driver here, and have
its BOM being imported by default. This is also how start.spring.io
website generates projects. Then you "just" add the dependencies (eg
typically named -starter).

If we have a number of Camel components that don't yet work this way,
we can then have them in some exclude list, and then do not generate a
-starter component. Then over time we can make them work with SB.

Also we may find out that if we change a version in parent/pom.xml to
align with SB then it could be a potential thing to do.



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

Re: Getting ready for Apache Camel 2.18 Release

[Nicola Ferraro]

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 get back in and figure out why the integration test is failing
> now
> >> - I was certain they were working at one time.  Anyway, the unit tests
> pass
> >> - but they generate a bunch of scary messages in the log files.  I
> didn’t
> >> see this stuff when I was using the class I derived
> CamelKarafTestSupport
> >> from.  If you have any ideas on how to clean those up, I’d really like
> to
> >> hear them.
> >>
> >> I’ve got one other bug to fix, then I’ll get back on this one.
> >>
> >> If you wouldn’t mind “watching” the JIRA for this (
> >> https://issues.apache.org/jira/browse/CAMEL-6132 <
> >> https://issues.apache.org/jira/browse/CAMEL-6132>), we can communicate
> >> there (rather than spam the 

Re: Getting ready for Apache Camel 2.18 Release

[Nicola Ferraro]

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  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 get back in and figure out why the integration test is failing now
> - I was certain they were working at one time.  Anyway, the unit tests pass
> - but they generate a bunch of scary messages in the log files.  I didn’t
> see this stuff when I was using the class I derived CamelKarafTestSupport
> from.  If you have any ideas on how to clean those up, I’d really like to
> hear them.
>
> I’ve got one other bug to fix, then I’ll get back on this one.
>
> If you wouldn’t mind “watching” the JIRA for this (
> https://issues.apache.org/jira/browse/CAMEL-6132 <
> https://issues.apache.org/jira/browse/CAMEL-6132>), we can communicate
> there (rather than spam the DEV list).
>
> Thanks Again
>
>
> > On Sep 8, 2016, at 11:09 AM, Walzer, Thomas <
> thomas.wal...@integratix.net> wrote:
> >
> > Hi, Quinn,
> >
> > I took a look at PR987:
> >
> > 1) the parent pom should be something like 2.18.0 not 2.18 (maybe the PR
> was around too long, so the parent changed).
> > 2) The readme really needs some love. It mentions spring when there is
> really blueprint; jms, when there is none, etc.
> > 3) for me an example replacing/redefining jms: or activemq: by seda:
> would really make a difference. Like having a jms-definitions-bp.xml and
> then replacing it by seda-definitions-bp.xml, or something like that. I
> know that´s not the point of your sample but the timer-example seems a bit
> basic.
> > 4) maybe …-test-karaf would be a better name?
> > 5) my unit tests and itests do not run through. If they would I could
> provide more fleshy feedback.
> >
> > If I can help, let me know.
> >
> > Cheers, Thomas.
> >
> > ---
> > T E S T S
> > ---
> > Running org.apache.camel.BlueprintBeanPropertiesOverrideFromFileTest
> > Unable to start bundle: org.apache.felix.gogo.runtime [64]
> > org.osgi.framework.BundleException: Unable to start bundle
> >   at org.apache.felix.connect.PojoSRBundle.start(
> PojoSRBundle.java:163)
> >   at org.apache.felix.connect.PojoSR.startBundles(PojoSR.java:304)
> >   at org.apache.felix.connect.PojoSR.(PojoSR.java:248)
> >   at org.apache.felix.connect.PojoSR.(PojoSR.java:129)
> >   at org.apache.felix.connect.PojoServiceRegistryFactoryImpl
> .newPojoServiceRegistry(PojoServiceRegistryFactoryImpl.java:52)
> >   at 

Re: Getting ready for Apache Camel 2.18 Release

[Quinn Stevenson]

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 get back in and figure out why the integration test is failing now - I 
was certain they were working at one time.  Anyway, the unit tests pass - but 
they generate a bunch of scary messages in the log files.  I didn’t see this 
stuff when I was using the class I derived CamelKarafTestSupport from.  If you 
have any ideas on how to clean those up, I’d really like to hear them.

I’ve got one other bug to fix, then I’ll get back on this one.  

If you wouldn’t mind “watching” the JIRA for this 
(https://issues.apache.org/jira/browse/CAMEL-6132 
), we can communicate there 
(rather than spam the DEV list).

Thanks Again


> On Sep 8, 2016, at 11:09 AM, Walzer, Thomas  
> wrote:
> 
> Hi, Quinn,
> 
> I took a look at PR987:
> 
> 1) the parent pom should be something like 2.18.0 not 2.18 (maybe the PR was 
> around too long, so the parent changed).
> 2) The readme really needs some love. It mentions spring when there is really 
> blueprint; jms, when there is none, etc.
> 3) for me an example replacing/redefining jms: or activemq: by seda: would 
> really make a difference. Like having a jms-definitions-bp.xml and then 
> replacing it by seda-definitions-bp.xml, or something like that. I know 
> that´s not the point of your sample but the timer-example seems a bit basic. 
> 4) maybe …-test-karaf would be a better name?
> 5) my unit tests and itests do not run through. If they would I could provide 
> more fleshy feedback.
> 
> If I can help, let me know.
> 
> Cheers, Thomas.
> 
> ---
> T E S T S
> ---
> Running org.apache.camel.BlueprintBeanPropertiesOverrideFromFileTest
> Unable to start bundle: org.apache.felix.gogo.runtime [64]
> org.osgi.framework.BundleException: Unable to start bundle
>   at org.apache.felix.connect.PojoSRBundle.start(PojoSRBundle.java:163)
>   at org.apache.felix.connect.PojoSR.startBundles(PojoSR.java:304)
>   at org.apache.felix.connect.PojoSR.(PojoSR.java:248)
>   at org.apache.felix.connect.PojoSR.(PojoSR.java:129)
>   at 
> org.apache.felix.connect.PojoServiceRegistryFactoryImpl.newPojoServiceRegistry(PojoServiceRegistryFactoryImpl.java:52)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintHelper.createBundleContext(CamelBlueprintHelper.java:173)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintHelper.createBundleContext(CamelBlueprintHelper.java:119)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.createBundleContext(CamelBlueprintTestSupport.java:127)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:241)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at 

Re: Getting ready for Apache Camel 2.18 Release

[Andrea Cosentino]

The docs now are completed. The last four languages were added.
 --
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Sunday, August 28, 2016 11:29 AM, Claus Ibsen  wrote:
Hi

Hope everybody had good summer vacation. I had my vacation in parts
and have next week as PTO.

We should get started to close down on the upcoming Camel 2.18 release.


There is some outstanding work (in no particular order)

1)
Finish the spring boot stuff with the starter components.
Nicola comes back from PTO and will work on this.

2)
rest-dsl to support calling REST services. I am working on this and
have some outstanding work still around binding and other
improvements.

3)
Tidy up the log4j v2 upgrade. Some of the examples do not start with
the jetty plugin.

4)
Migrate the last wiki pages to adoc files. There is not so many pages
left and you can find a report when running camel-catalog build that
output what is missing.

This will help us with a base-line for maintaining the documentation
going forward in the source code adoc files instead of wiki, and we
can then generate a new website and documentation for the following
release (2.19 or 3.0) etc. But this is a discussion we should IMHO
take post 2.18.

5)
camel-test-karaf module. This module is in the works but could use
some review and finishing so its easier to use for end users.

Notice the existing camel-test-blueprint is still favored for doing
unit tests which you can run fast and easily debug. The new
camel-test-karaf is for running integration tests in a running karaf
instance.

6)
We should look at the JIRA tickets that are assigned to 2.18.0 and try
to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
releases.

7)
Keep an eye on the CI server to make sure the tests are green.
https://builds.apache.org/view/A-D/view/Camel/


If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 RC.




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

Re: Getting ready for Apache Camel 2.18 Release

[Walzer, Thomas]

Hi, Quinn,

I took a look at PR987:

1) the parent pom should be something like 2.18.0 not 2.18 (maybe the PR was 
around too long, so the parent changed).
2) The readme really needs some love. It mentions spring when there is really 
blueprint; jms, when there is none, etc.
3) for me an example replacing/redefining jms: or activemq: by seda: would 
really make a difference. Like having a jms-definitions-bp.xml and then 
replacing it by seda-definitions-bp.xml, or something like that. I know that´s 
not the point of your sample but the timer-example seems a bit basic. 
4) maybe …-test-karaf would be a better name?
5) my unit tests and itests do not run through. If they would I could provide 
more fleshy feedback.

If I can help, let me know.

Cheers, Thomas.

---
 T E S T S
---
Running org.apache.camel.BlueprintBeanPropertiesOverrideFromFileTest
Unable to start bundle: org.apache.felix.gogo.runtime [64]
org.osgi.framework.BundleException: Unable to start bundle
at org.apache.felix.connect.PojoSRBundle.start(PojoSRBundle.java:163)
at org.apache.felix.connect.PojoSR.startBundles(PojoSR.java:304)
at org.apache.felix.connect.PojoSR.(PojoSR.java:248)
at org.apache.felix.connect.PojoSR.(PojoSR.java:129)
at 
org.apache.felix.connect.PojoServiceRegistryFactoryImpl.newPojoServiceRegistry(PojoServiceRegistryFactoryImpl.java:52)
at 
org.apache.camel.test.blueprint.CamelBlueprintHelper.createBundleContext(CamelBlueprintHelper.java:173)
at 
org.apache.camel.test.blueprint.CamelBlueprintHelper.createBundleContext(CamelBlueprintHelper.java:119)
at 
org.apache.camel.test.blueprint.CamelBlueprintTestSupport.createBundleContext(CamelBlueprintTestSupport.java:127)
at 
org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:241)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Caused by: java.lang.IllegalStateException: Thread Print Stream already set
at 
org.apache.felix.gogo.runtime.threadio.ThreadIOImpl.start(ThreadIOImpl.java:49)
at 
org.apache.felix.gogo.runtime.activator.Activator.start(Activator.java:76)
at org.apache.felix.connect.PojoSRBundle.start(PojoSRBundle.java:153)
... 37 more
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.485 sec - in 
org.apache.camel.BlueprintBeanPropertiesOverrideFromFileTest
Running org.apache.camel.BlueprintBeanPropertiesOverrideFromTestTest
Unable to 

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi

I added to our maven tool that it can fail the build if our component
docs has problems.

You can set this value to true
https://github.com/apache/camel/blob/master/components/pom.xml#L286

And then do a mvn clean install -Dtest=false in the components directory.

There seems to be a bunch of .adoc files which have no START .. END
markers. I fixed a bunch in the start, but only got as far as to
camel-dropbox to fail.

We should get all these corrected as well.





On Tue, Sep 6, 2016 at 1:08 PM, Andrea Cosentino
 wrote:
> For the docs, I should be able to complete the languages this week.
>
> :-)
>  --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Tuesday, September 6, 2016 1:05 PM, Claus Ibsen  
> wrote:
> On Sun, Aug 28, 2016 at 11:28 AM, Claus Ibsen  wrote:
>> Hi
>>
>> Hope everybody had good summer vacation. I had my vacation in parts
>> and have next week as PTO.
>>
>> We should get started to close down on the upcoming Camel 2.18 release.
>>
>>
>> There is some outstanding work (in no particular order)
>>
>> 1)
>> Finish the spring boot stuff with the starter components.
>> Nicola comes back from PTO and will work on this.
>>
>
> Still pending.
>
>> 2)
>> rest-dsl to support calling REST services. I am working on this and
>> have some outstanding work still around binding and other
>> improvements.
>>
>
> Implemented.
>
>> 3)
>> Tidy up the log4j v2 upgrade. Some of the examples do not start with
>> the jetty plugin.
>>
>
> Fixed.
>
>> 4)
>> Migrate the last wiki pages to adoc files. There is not so many pages
>> left and you can find a report when running camel-catalog build that
>> output what is missing.
>>
>> This will help us with a base-line for maintaining the documentation
>> going forward in the source code adoc files instead of wiki, and we
>> can then generate a new website and documentation for the following
>> release (2.19 or 3.0) etc. But this is a discussion we should IMHO
>> take post 2.18.
>>
>
> Pending.
>
> Andreas have migrate a bunch more wiki pages, but we still have a few
> left for languages:
>
> [WARNING]   Missing .adoc language documentation  : 4
> [WARNING]   file-language
> [WARNING]   simple-language
> [WARNING]   xpath-language
> [WARNING]   xquery-language
>
>
> And then we need to migrate all the EIP patterns. We may postpone this
> to post 2.18, as I would like to also get EIPs generate their options
> automatic as we do for components.
>
> Also we have a experiment with generate a list of the EIPs at
> https://github.com/apache/camel/blob/master/camel-core/readme-eip.adoc
>
>
>> 5)
>> camel-test-karaf module. This module is in the works but could use
>> some review and finishing so its easier to use for end users.
>>
>> Notice the existing camel-test-blueprint is still favored for doing
>> unit tests which you can run fast and easily debug. The new
>> camel-test-karaf is for running integration tests in a running karaf
>> instance.
>>
>
> Pending. Need to find time to help review and finish this.
>
>
>> 6)
>> We should look at the JIRA tickets that are assigned to 2.18.0 and try
>> to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
>> releases.
>>
>
> Pending.
>
>> 7)
>> Keep an eye on the CI server to make sure the tests are green.
>> https://builds.apache.org/view/A-D/view/Camel/
>>
>
> In general good state but the CI servers sometimes cannot build due to
> low memory or other jenkinis issues.
>
>>
>> If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 
>> RC.
>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



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

Re: Getting ready for Apache Camel 2.18 Release

[Andrea Cosentino]

For the docs, I should be able to complete the languages this week.

:-)
 --
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Tuesday, September 6, 2016 1:05 PM, Claus Ibsen  
wrote:
On Sun, Aug 28, 2016 at 11:28 AM, Claus Ibsen  wrote:
> Hi
>
> Hope everybody had good summer vacation. I had my vacation in parts
> and have next week as PTO.
>
> We should get started to close down on the upcoming Camel 2.18 release.
>
>
> There is some outstanding work (in no particular order)
>
> 1)
> Finish the spring boot stuff with the starter components.
> Nicola comes back from PTO and will work on this.
>

Still pending.

> 2)
> rest-dsl to support calling REST services. I am working on this and
> have some outstanding work still around binding and other
> improvements.
>

Implemented.

> 3)
> Tidy up the log4j v2 upgrade. Some of the examples do not start with
> the jetty plugin.
>

Fixed.

> 4)
> Migrate the last wiki pages to adoc files. There is not so many pages
> left and you can find a report when running camel-catalog build that
> output what is missing.
>
> This will help us with a base-line for maintaining the documentation
> going forward in the source code adoc files instead of wiki, and we
> can then generate a new website and documentation for the following
> release (2.19 or 3.0) etc. But this is a discussion we should IMHO
> take post 2.18.
>

Pending.

Andreas have migrate a bunch more wiki pages, but we still have a few
left for languages:

[WARNING]   Missing .adoc language documentation  : 4
[WARNING]   file-language
[WARNING]   simple-language
[WARNING]   xpath-language
[WARNING]   xquery-language


And then we need to migrate all the EIP patterns. We may postpone this
to post 2.18, as I would like to also get EIPs generate their options
automatic as we do for components.

Also we have a experiment with generate a list of the EIPs at
https://github.com/apache/camel/blob/master/camel-core/readme-eip.adoc


> 5)
> camel-test-karaf module. This module is in the works but could use
> some review and finishing so its easier to use for end users.
>
> Notice the existing camel-test-blueprint is still favored for doing
> unit tests which you can run fast and easily debug. The new
> camel-test-karaf is for running integration tests in a running karaf
> instance.
>

Pending. Need to find time to help review and finish this.


> 6)
> We should look at the JIRA tickets that are assigned to 2.18.0 and try
> to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
> releases.
>

Pending.

> 7)
> Keep an eye on the CI server to make sure the tests are green.
> https://builds.apache.org/view/A-D/view/Camel/
>

In general good state but the CI servers sometimes cannot build due to
low memory or other jenkinis issues.

>
> If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 
> RC.
>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2




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

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

On Sun, Aug 28, 2016 at 11:28 AM, Claus Ibsen  wrote:
> Hi
>
> Hope everybody had good summer vacation. I had my vacation in parts
> and have next week as PTO.
>
> We should get started to close down on the upcoming Camel 2.18 release.
>
>
> There is some outstanding work (in no particular order)
>
> 1)
> Finish the spring boot stuff with the starter components.
> Nicola comes back from PTO and will work on this.
>

Still pending.

> 2)
> rest-dsl to support calling REST services. I am working on this and
> have some outstanding work still around binding and other
> improvements.
>

Implemented.

> 3)
> Tidy up the log4j v2 upgrade. Some of the examples do not start with
> the jetty plugin.
>

Fixed.

> 4)
> Migrate the last wiki pages to adoc files. There is not so many pages
> left and you can find a report when running camel-catalog build that
> output what is missing.
>
> This will help us with a base-line for maintaining the documentation
> going forward in the source code adoc files instead of wiki, and we
> can then generate a new website and documentation for the following
> release (2.19 or 3.0) etc. But this is a discussion we should IMHO
> take post 2.18.
>

Pending.

Andreas have migrate a bunch more wiki pages, but we still have a few
left for languages:

[WARNING]   Missing .adoc language documentation  : 4
[WARNING]   file-language
[WARNING]   simple-language
[WARNING]   xpath-language
[WARNING]   xquery-language


And then we need to migrate all the EIP patterns. We may postpone this
to post 2.18, as I would like to also get EIPs generate their options
automatic as we do for components.

Also we have a experiment with generate a list of the EIPs at
https://github.com/apache/camel/blob/master/camel-core/readme-eip.adoc


> 5)
> camel-test-karaf module. This module is in the works but could use
> some review and finishing so its easier to use for end users.
>
> Notice the existing camel-test-blueprint is still favored for doing
> unit tests which you can run fast and easily debug. The new
> camel-test-karaf is for running integration tests in a running karaf
> instance.
>

Pending. Need to find time to help review and finish this.


> 6)
> We should look at the JIRA tickets that are assigned to 2.18.0 and try
> to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
> releases.
>

Pending.

> 7)
> Keep an eye on the CI server to make sure the tests are green.
> https://builds.apache.org/view/A-D/view/Camel/
>

In general good state but the CI servers sometimes cannot build due to
low memory or other jenkinis issues.

>
> If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 
> RC.
>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



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

Re: Getting ready for Apache Camel 2.18 Release

[Quinn Stevenson]

I’ve had a pull-request out there for a while 
(https://github.com/apache/camel/pull/987 
) - looking for some feedback on the 
example project that attempts to show how to use camel-test-karaf.  I could 
really use some input.  I think fleshing-out this example will help refine the 
camel-test-karaf component itself.


> On Aug 30, 2016, at 4:17 AM, Luca Burgazzoli  wrote:
> 
> Hi Claus,
> 
> Yep, I'm going to close CAMEL-10274.
> 
> ---
> Luca Burgazzoli
> 
> 
> On Tue, Aug 30, 2016 at 11:25 AM, Claus Ibsen  wrote:
>> Hi Luca
>> 
>> I can see you found out about the problem and found a solution. So the
>> examples should work again.
>> 
>> On Mon, Aug 29, 2016 at 12:39 PM, Luca Burgazzoli  
>> wrote:
>>> Hi Claus,
>>> 
>>> can you tell me something more about log4j2 vs jetty plugin ?
>>> 
>>> ---
>>> Luca Burgazzoli
>>> 
>>> 
>>> On Sun, Aug 28, 2016 at 11:28 AM, Claus Ibsen  wrote:
 Hi
 
 Hope everybody had good summer vacation. I had my vacation in parts
 and have next week as PTO.
 
 We should get started to close down on the upcoming Camel 2.18 release.
 
 
 There is some outstanding work (in no particular order)
 
 1)
 Finish the spring boot stuff with the starter components.
 Nicola comes back from PTO and will work on this.
 
 2)
 rest-dsl to support calling REST services. I am working on this and
 have some outstanding work still around binding and other
 improvements.
 
 3)
 Tidy up the log4j v2 upgrade. Some of the examples do not start with
 the jetty plugin.
 
 4)
 Migrate the last wiki pages to adoc files. There is not so many pages
 left and you can find a report when running camel-catalog build that
 output what is missing.
 
 This will help us with a base-line for maintaining the documentation
 going forward in the source code adoc files instead of wiki, and we
 can then generate a new website and documentation for the following
 release (2.19 or 3.0) etc. But this is a discussion we should IMHO
 take post 2.18.
 
 5)
 camel-test-karaf module. This module is in the works but could use
 some review and finishing so its easier to use for end users.
 
 Notice the existing camel-test-blueprint is still favored for doing
 unit tests which you can run fast and easily debug. The new
 camel-test-karaf is for running integration tests in a running karaf
 instance.
 
 6)
 We should look at the JIRA tickets that are assigned to 2.18.0 and try
 to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
 releases.
 
 7)
 Keep an eye on the CI server to make sure the tests are green.
 https://builds.apache.org/view/A-D/view/Camel/
 
 
 If all goes well then hopefully in 2-3 weeks we are ready to cut the 
 2.18.0 RC.
 
 
 
 
 --
 Claus Ibsen
 -
 http://davsclaus.com @davsclaus
 Camel in Action 2: https://www.manning.com/ibsen2
>> 
>> 
>> 
>> --
>> Claus Ibsen
>> -
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2

Re: Getting ready for Apache Camel 2.18 Release

[Luca Burgazzoli]

Hi Claus,

Yep, I'm going to close CAMEL-10274.

---
Luca Burgazzoli


On Tue, Aug 30, 2016 at 11:25 AM, Claus Ibsen  wrote:
> Hi Luca
>
> I can see you found out about the problem and found a solution. So the
> examples should work again.
>
> On Mon, Aug 29, 2016 at 12:39 PM, Luca Burgazzoli  
> wrote:
>> Hi Claus,
>>
>> can you tell me something more about log4j2 vs jetty plugin ?
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Sun, Aug 28, 2016 at 11:28 AM, Claus Ibsen  wrote:
>>> Hi
>>>
>>> Hope everybody had good summer vacation. I had my vacation in parts
>>> and have next week as PTO.
>>>
>>> We should get started to close down on the upcoming Camel 2.18 release.
>>>
>>>
>>> There is some outstanding work (in no particular order)
>>>
>>> 1)
>>> Finish the spring boot stuff with the starter components.
>>> Nicola comes back from PTO and will work on this.
>>>
>>> 2)
>>> rest-dsl to support calling REST services. I am working on this and
>>> have some outstanding work still around binding and other
>>> improvements.
>>>
>>> 3)
>>> Tidy up the log4j v2 upgrade. Some of the examples do not start with
>>> the jetty plugin.
>>>
>>> 4)
>>> Migrate the last wiki pages to adoc files. There is not so many pages
>>> left and you can find a report when running camel-catalog build that
>>> output what is missing.
>>>
>>> This will help us with a base-line for maintaining the documentation
>>> going forward in the source code adoc files instead of wiki, and we
>>> can then generate a new website and documentation for the following
>>> release (2.19 or 3.0) etc. But this is a discussion we should IMHO
>>> take post 2.18.
>>>
>>> 5)
>>> camel-test-karaf module. This module is in the works but could use
>>> some review and finishing so its easier to use for end users.
>>>
>>> Notice the existing camel-test-blueprint is still favored for doing
>>> unit tests which you can run fast and easily debug. The new
>>> camel-test-karaf is for running integration tests in a running karaf
>>> instance.
>>>
>>> 6)
>>> We should look at the JIRA tickets that are assigned to 2.18.0 and try
>>> to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
>>> releases.
>>>
>>> 7)
>>> Keep an eye on the CI server to make sure the tests are green.
>>> https://builds.apache.org/view/A-D/view/Camel/
>>>
>>>
>>> If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 
>>> RC.
>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi Luca

I can see you found out about the problem and found a solution. So the
examples should work again.

On Mon, Aug 29, 2016 at 12:39 PM, Luca Burgazzoli  wrote:
> Hi Claus,
>
> can you tell me something more about log4j2 vs jetty plugin ?
>
> ---
> Luca Burgazzoli
>
>
> On Sun, Aug 28, 2016 at 11:28 AM, Claus Ibsen  wrote:
>> Hi
>>
>> Hope everybody had good summer vacation. I had my vacation in parts
>> and have next week as PTO.
>>
>> We should get started to close down on the upcoming Camel 2.18 release.
>>
>>
>> There is some outstanding work (in no particular order)
>>
>> 1)
>> Finish the spring boot stuff with the starter components.
>> Nicola comes back from PTO and will work on this.
>>
>> 2)
>> rest-dsl to support calling REST services. I am working on this and
>> have some outstanding work still around binding and other
>> improvements.
>>
>> 3)
>> Tidy up the log4j v2 upgrade. Some of the examples do not start with
>> the jetty plugin.
>>
>> 4)
>> Migrate the last wiki pages to adoc files. There is not so many pages
>> left and you can find a report when running camel-catalog build that
>> output what is missing.
>>
>> This will help us with a base-line for maintaining the documentation
>> going forward in the source code adoc files instead of wiki, and we
>> can then generate a new website and documentation for the following
>> release (2.19 or 3.0) etc. But this is a discussion we should IMHO
>> take post 2.18.
>>
>> 5)
>> camel-test-karaf module. This module is in the works but could use
>> some review and finishing so its easier to use for end users.
>>
>> Notice the existing camel-test-blueprint is still favored for doing
>> unit tests which you can run fast and easily debug. The new
>> camel-test-karaf is for running integration tests in a running karaf
>> instance.
>>
>> 6)
>> We should look at the JIRA tickets that are assigned to 2.18.0 and try
>> to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
>> releases.
>>
>> 7)
>> Keep an eye on the CI server to make sure the tests are green.
>> https://builds.apache.org/view/A-D/view/Camel/
>>
>>
>> If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 
>> RC.
>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2



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

Re: Getting ready for Apache Camel 2.18 Release

[Luca Burgazzoli]

Hi Claus,

can you tell me something more about log4j2 vs jetty plugin ?

---
Luca Burgazzoli


On Sun, Aug 28, 2016 at 11:28 AM, Claus Ibsen  wrote:
> Hi
>
> Hope everybody had good summer vacation. I had my vacation in parts
> and have next week as PTO.
>
> We should get started to close down on the upcoming Camel 2.18 release.
>
>
> There is some outstanding work (in no particular order)
>
> 1)
> Finish the spring boot stuff with the starter components.
> Nicola comes back from PTO and will work on this.
>
> 2)
> rest-dsl to support calling REST services. I am working on this and
> have some outstanding work still around binding and other
> improvements.
>
> 3)
> Tidy up the log4j v2 upgrade. Some of the examples do not start with
> the jetty plugin.
>
> 4)
> Migrate the last wiki pages to adoc files. There is not so many pages
> left and you can find a report when running camel-catalog build that
> output what is missing.
>
> This will help us with a base-line for maintaining the documentation
> going forward in the source code adoc files instead of wiki, and we
> can then generate a new website and documentation for the following
> release (2.19 or 3.0) etc. But this is a discussion we should IMHO
> take post 2.18.
>
> 5)
> camel-test-karaf module. This module is in the works but could use
> some review and finishing so its easier to use for end users.
>
> Notice the existing camel-test-blueprint is still favored for doing
> unit tests which you can run fast and easily debug. The new
> camel-test-karaf is for running integration tests in a running karaf
> instance.
>
> 6)
> We should look at the JIRA tickets that are assigned to 2.18.0 and try
> to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
> releases.
>
> 7)
> Keep an eye on the CI server to make sure the tests are green.
> https://builds.apache.org/view/A-D/view/Camel/
>
>
> If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 
> RC.
>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Getting ready for Apache Camel 2.18 Release

[Claus Ibsen]

Hi

Hope everybody had good summer vacation. I had my vacation in parts
and have next week as PTO.

We should get started to close down on the upcoming Camel 2.18 release.


There is some outstanding work (in no particular order)

1)
Finish the spring boot stuff with the starter components.
Nicola comes back from PTO and will work on this.

2)
rest-dsl to support calling REST services. I am working on this and
have some outstanding work still around binding and other
improvements.

3)
Tidy up the log4j v2 upgrade. Some of the examples do not start with
the jetty plugin.

4)
Migrate the last wiki pages to adoc files. There is not so many pages
left and you can find a report when running camel-catalog build that
output what is missing.

This will help us with a base-line for maintaining the documentation
going forward in the source code adoc files instead of wiki, and we
can then generate a new website and documentation for the following
release (2.19 or 3.0) etc. But this is a discussion we should IMHO
take post 2.18.

5)
camel-test-karaf module. This module is in the works but could use
some review and finishing so its easier to use for end users.

Notice the existing camel-test-blueprint is still favored for doing
unit tests which you can run fast and easily debug. The new
camel-test-karaf is for running integration tests in a running karaf
instance.

6)
We should look at the JIRA tickets that are assigned to 2.18.0 and try
to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
releases.

7)
Keep an eye on the CI server to make sure the tests are green.
https://builds.apache.org/view/A-D/view/Camel/


If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 RC.




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