[PROPOSAL] (was: [VOTE] Release Apache Camel 2.7.0)

[Hadrian Zbarcea <hz...@gmail.com>]

We knew this patch will go in, now or 2.8.0 which meant that the compatibility with karaf 2.1.x will be broken at some point. There is no real difference if we do it now or in 2.8.0 if 2.8.0 is released soon. If 2.8.0 is released much later, we give users something that is java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does already anyway), but we could negatively impact smx 4.4. Traditionally during the Camel lifetime we played very nice with other communities, especially those that rely directly on Camel.

That said, my proposal is this:
1. We keep Jean Baptiste's patch.
2. JB opened and KARAF-505 and will commit a patch soon. As of the next Karaf 2.1.5 the compatibility will be restored.
3. We release Camel 2.7.0 either:
 a. after a few days of testing (per Christian proposal, +1'd by Claus); the only impact of the patch is using the new obr features in Karaf 2.2.0 (which was tested, contrary to allegations), no other impacts; this leaves a few weeks of incompatibility from the Camel release to the Karaf 2.1.5 release
 b. after the Karaf 2.1.5 release

Personally I am ok with either 3a or 3b opting slightly towards 3a. If you have other proposals or a preference please speak up. I hope us to be in position to make a decision early next week.

Thanks,
Hadrian



On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:

> Hi
> 
> On Thursday, March 10, 2011, Christian Schneider <cs...@talend.com> wrote:
>> Hi all,
>> 
>> I think the same way as Claus. We should try to not add any functional changes a few days before a release. That is the only way to make sure people have time to run their tests against the code base to be released.
>> I was already hesitant to commit my patch for the servlet on friday.
>> 
>> So I think we have two options for the features.xml issue. If it is really important for 2.7.0 we do a new release with it included in some days. If not we cut a release now with the reverted version, perhaps with Willems fixes.
> 
> Yeah as christian says i think we got two options.
> 1) re cut release without the features patch
> 2) apply the patch and postpone the release for a week or longer, to
> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
> the given jira ticket.
> 
> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
> needs a camel with karaf 2.2 and that features patch. Although we are
> very likely to be able to cut a new camel 2.8 release beforehand.
> 
> I am traveling for the next two weeks, so you guys can have fun
> without me policing.
> In light of this and the fact smx 4,4 need the patch, i am okay for
> either option.
> 
> 
>> 
>> So I think what we should do is define a code freeze some days before a release. During this time we should only commit bug fixes but not functional changes. In a less formal way we already do this.
>> If we think this could slow down progress on the trunk then we could at this point create a branch for the release.
>> 
> 
> Yeah we are usually good at having a slowdown up til the release is
> cut. This time we had five or more days, which was really good. The
> last major func. Change was that servlet improvements which imho is a
> very good improvement. After this we fixed all the maven archetypes so
> they are working again. Other than that its bug fixes and test fixes
> leading up till the cut time.
> 
> 
> 
>> Christian
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>> Gesendet: Donnerstag, 10. März 2011 11:44
>> An: dev@camel.apache.org
>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>> 
>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> 
>>> 
>>> I see now that Willem already reverted the patch, not clear why, I assume just based on your feelings. I would be very interested in seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>> 
>> 
>> I really dont understand why you would think its "no brainer" to make such a big change "seconds" before you cut the release.
>> You are usually very good and careful when you do the releases.
>> 
>> The ticket its not a blocker for the 2.7 release. And it was already scheduled for Camel 2.8.
>> And in terms of OSGi you have to be extra careful and test it more thoroughly than a simpler fix in a plain Camel component.
>> The OSGi tests runs at the end of the CI process and thus they are more prone to not be run due test failures in pre-existing components.
>> We all know it can be a little tricky to have CI 100% green.
>> Hence its a good practice to also run those OSGi tests locally once in a while to ensure it works well.
>> 
>> 
>> 
> 
> -- 
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/

Re: [PROPOSAL]

[Willem Jiang <wi...@gmail.com>]

Hi Andreas,

Thanks for your help,
I just sent a mail with the below patch to the Karaf dev mailing list to 
ask for help.

You can see the error easily by apply the blow patch.

diff --git 
a/itests/tests/src/test/java/org/apache/karaf/shell/itests/FeaturesTest.java 
b/itests/tes
index 074a29e..cb57b25 100644
--- 
a/itests/tests/src/test/java/org/apache/karaf/shell/itests/FeaturesTest.java
+++ 
b/itests/tests/src/test/java/org/apache/karaf/shell/itests/FeaturesTest.java
@@ -61,6 +61,7 @@ public class FeaturesTest extends 
AbstractIntegrationTest {

              // add two features
              Helper.loadKarafStandardFeatures("obr", "wrapper"),
+            Helper.loadKarafStandardFeatures("spring", "http"),

              workingDirectory("target/paxrunner/features/"),


Willem

On 3/16/11 3:16 PM, Andreas Pieber wrote:
> Hey Willem,
>
> On Wed, Mar 16, 2011 at 4:59 AM, Willem Jiang<wi...@gmail.com>  wrote:
>> I updated the camel itest-osgi-karaf to use Pax-Exam 1.2.4, it looks like
>> current pax-exam doesn't support the new features of Karaf-2.2.0.
>
> Interesting, but 1.2.4 is based on karaf-2.2.0 (at least the scanner
> component) and I'm running integration tests based on it. Can you
> please file the problems as issues for pax-exam? Than I can take a
> detailed look what's missing for your use cases.
>
>> As karaf stand feature has more than on Spring feature, it's hard to let the
>> pax-exam to tell which version of feature it should load. So the Pax-Exam
>> tests can't be started rightly.
>
> Sorry, but I'm confused again: you can add versions to features (using
> the<feature>  tag in your features.xml or using scan-feature).
> Otherwise the latest will be used by default.
>
>> Before upgrading to new version of Pax-Exam which fixed that issue, we can't
>> run camel integration tests successfully.
>>
>> I will check the karaf integration tests today, to see if there is other
>> solution for this kind of issue.
>
> Feel free to ask for help. I did already some more complex integration
> testing based on karaf and exam than we do in Karaf itself.
>
> Kind regards,
> Andreas
>
>>
>> Willem
>>
>> On 3/15/11 10:31 PM, Andreas Pieber wrote:
>>>
>>> Hey Willem, JB,
>>>
>>> If I understand you correctly this problem should only affect 2.2.x
>>> branch but not the master. The problem should be, AFAIK that we use
>>> pax-exam 1.2.3 in karaf-2.2 which uses an old version of karaf. I'll
>>> upgrade 2.2.x to exam 1.2.4. Can you please check if this fixes your
>>> problems?
>>>
>>> Kind regards,
>>> Andreas



-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang

Re: [PROPOSAL]

[Andreas Pieber <an...@gmail.com>]

Hey Willem,

On Wed, Mar 16, 2011 at 4:59 AM, Willem Jiang <wi...@gmail.com> wrote:
> I updated the camel itest-osgi-karaf to use Pax-Exam 1.2.4, it looks like
> current pax-exam doesn't support the new features of Karaf-2.2.0.

Interesting, but 1.2.4 is based on karaf-2.2.0 (at least the scanner
component) and I'm running integration tests based on it. Can you
please file the problems as issues for pax-exam? Than I can take a
detailed look what's missing for your use cases.

> As karaf stand feature has more than on Spring feature, it's hard to let the
> pax-exam to tell which version of feature it should load. So the Pax-Exam
> tests can't be started rightly.

Sorry, but I'm confused again: you can add versions to features (using
the <feature> tag in your features.xml or using scan-feature).
Otherwise the latest will be used by default.

> Before upgrading to new version of Pax-Exam which fixed that issue, we can't
> run camel integration tests successfully.
>
> I will check the karaf integration tests today, to see if there is other
> solution for this kind of issue.

Feel free to ask for help. I did already some more complex integration
testing based on karaf and exam than we do in Karaf itself.

Kind regards,
Andreas

>
> Willem
>
> On 3/15/11 10:31 PM, Andreas Pieber wrote:
>>
>> Hey Willem, JB,
>>
>> If I understand you correctly this problem should only affect 2.2.x
>> branch but not the master. The problem should be, AFAIK that we use
>> pax-exam 1.2.3 in karaf-2.2 which uses an old version of karaf. I'll
>> upgrade 2.2.x to exam 1.2.4. Can you please check if this fixes your
>> problems?
>>
>> Kind regards,
>> Andreas
>>
>> On Tue, Mar 15, 2011 at 2:18 PM, Jean-Baptiste Onofré<jb...@nanthrax.net>
>>  wrote:
>>>
>>> Hi Willem,
>>>
>>> thanks for your tests.
>>>
>>> I'm gonna check your issue (I will discuss with you on IRC around that).
>>>
>>> Regards
>>> JB
>>>
>>> On 03/15/2011 02:18 PM, Willem Jiang wrote:
>>>>
>>>> I just ran the itest-osgi-karaf with the latest patch, and found current
>>>> PaxExam doesn't support to load two features with different versions or
>>>> load the features from other features file, so current camel osgi
>>>> integration tests doesn't work with the patched camel-feature.
>>>>
>>>> I'm not sure how the Karaf tests it feature file, maybe JB can help me
>>>> resolve this kind of issue.
>>>>
>>>> As we may need to use new version of PaxExam to load the karaf 2.2.0
>>>> features file, it will take some time for us to fix the tests. My
>>>> suggestion is we ship the features which supports Karaf 2.1.4 as a
>>>> verified feature, and leave the features of Karaf 2.2.0 as an experiment
>>>> release.
>>>> In Camel 2.8.0 we can drop the support of Karaf 2.1.4.
>>>>
>>>> Any thought?
>>>>
>>>>
>>>> On 3/14/11 11:57 PM, Jean-Baptiste Onofré wrote:
>>>>>
>>>>> Agree Hadrian,
>>>>>
>>>>> I think it's more "logical" to have:
>>>>> - Camel 2.7 supports only Karaf 2.2.x
>>>>> - ServiceMix 4.4.0 (powered by Karaf 2.2.x) will ship Camel 2.7
>>>>> - if users want to stay with Karaf 2.1.x, they have to use Camel 2.6
>>>>>
>>>>> It sounds like a good plan for me :)
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 03/14/2011 03:55 PM, Hadrian Zbarcea wrote:
>>>>>>
>>>>>> If that's the case, this looks to me like not very useful. I am not
>>>>>> against it, but it seems like a nice to have unnecessary effort. Users
>>>>>> can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility
>>>>>> with so many technologies, like Java 1.5. and Spring 2.5.x, to me
>>>>>> Karaf 2.1.x is just a drop in the bucket. That's of course based on
>>>>>> the assumption that very few will use the deprecated 2.1.x in
>>>>>> production. It takes weeks to months to roll a new version (of Camel
>>>>>> or anything else) in production.
>>>>>>
>>>>>> My $0.02,
>>>>>> Hadrian
>>>>>>
>>>>>>
>>>>>> On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant
>>>>>>> features descriptor, the main changes are:
>>>>>>> - the name of the jetty feature and jetty version used
>>>>>>> - the avoid of resolver
>>>>>>>
>>>>>>> I will add this feature descriptor patch.
>>>>>>>
>>>>>>> However, I think that for Camel 2.8, we have to "break" the Karaf
>>>>>>> 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf
>>>>>>> 2.1.x will go to deprecation soon :)
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>>>>>>>
>>>>>>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>>>>>>> rightly.
>>>>>>>>
>>>>>>>> I think we can provide another Feature.xml file like we did in Camel
>>>>>>>> 2.6.0 to support the spring 2.5.x.
>>>>>>>> In this case we could just provide another Features.xml which
>>>>>>>> supports
>>>>>>>> the Karaf 2.1.4 etc.
>>>>>>>>
>>>>>>>> Willem
>>>>>>>>
>>>>>>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>>>>>>>
>>>>>>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>>>>>>> compatibility with karaf 2.1.x will be broken at some point. There
>>>>>>>>> is
>>>>>>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>>>>>>> soon. If 2.8.0 is released much later, we give users something
>>>>>>>>> that is
>>>>>>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>>>>>>> already anyway), but we could negatively impact smx 4.4.
>>>>>>>>> Traditionally
>>>>>>>>> during the Camel lifetime we played very nice with other
>>>>>>>>> communities,
>>>>>>>>> especially those that rely directly on Camel.
>>>>>>>>>
>>>>>>>>> That said, my proposal is this:
>>>>>>>>> 1. We keep Jean Baptiste's patch.
>>>>>>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>>>>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>>>>>>> 3. We release Camel 2.7.0 either:
>>>>>>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>>>>>>> Claus); the only impact of the patch is using the new obr features
>>>>>>>>> in
>>>>>>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>>>>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>>>>>>> release to the Karaf 2.1.5 release
>>>>>>>>> b. after the Karaf 2.1.5 release
>>>>>>>>>
>>>>>>>>> Personally I am ok with either 3a or 3b opting slightly towards
>>>>>>>>> 3a. If
>>>>>>>>> you have other proposals or a preference please speak up. I hope
>>>>>>>>> us to
>>>>>>>>> be in position to make a decision early next week.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Hadrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> On Thursday, March 10, 2011, Christian
>>>>>>>>>> Schneider<cs...@talend.com>  wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I think the same way as Claus. We should try to not add any
>>>>>>>>>>> functional changes a few days before a release. That is the only
>>>>>>>>>>> way
>>>>>>>>>>> to make sure people have time to run their tests against the code
>>>>>>>>>>> base to be released.
>>>>>>>>>>> I was already hesitant to commit my patch for the servlet on
>>>>>>>>>>> friday.
>>>>>>>>>>>
>>>>>>>>>>> So I think we have two options for the features.xml issue. If it
>>>>>>>>>>> is
>>>>>>>>>>> really important for 2.7.0 we do a new release with it included
>>>>>>>>>>> in
>>>>>>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>>>>>>> perhaps with Willems fixes.
>>>>>>>>>>
>>>>>>>>>> Yeah as christian says i think we got two options.
>>>>>>>>>> 1) re cut release without the features patch
>>>>>>>>>> 2) apply the patch and postpone the release for a week or longer,
>>>>>>>>>> to
>>>>>>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also
>>>>>>>>>> mean
>>>>>>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by
>>>>>>>>>> jean in
>>>>>>>>>> the given jira ticket.
>>>>>>>>>>
>>>>>>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4
>>>>>>>>>> which
>>>>>>>>>> needs a camel with karaf 2.2 and that features patch. Although we
>>>>>>>>>> are
>>>>>>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>>>>>>
>>>>>>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>>>>>>> without me policing.
>>>>>>>>>> In light of this and the fact smx 4,4 need the patch, i am okay
>>>>>>>>>> for
>>>>>>>>>> either option.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So I think what we should do is define a code freeze some days
>>>>>>>>>>> before a release. During this time we should only commit bug
>>>>>>>>>>> fixes
>>>>>>>>>>> but not functional changes. In a less formal way we already do
>>>>>>>>>>> this.
>>>>>>>>>>> If we think this could slow down progress on the trunk then we
>>>>>>>>>>> could
>>>>>>>>>>> at this point create a branch for the release.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yeah we are usually good at having a slowdown up til the release
>>>>>>>>>> is
>>>>>>>>>> cut. This time we had five or more days, which was really good.
>>>>>>>>>> The
>>>>>>>>>> last major func. Change was that servlet improvements which imho
>>>>>>>>>> is a
>>>>>>>>>> very good improvement. After this we fixed all the maven
>>>>>>>>>> archetypes so
>>>>>>>>>> they are working again. Other than that its bug fixes and test
>>>>>>>>>> fixes
>>>>>>>>>> leading up till the cut time.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Christian
>>>>>>>>>>>
>>>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>>>>>>> An: dev@camel.apache.org
>>>>>>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>>>>>>> Zbarcea<hz...@gmail.com>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I see now that Willem already reverted the patch, not clear why,
>>>>>>>>>>>> I
>>>>>>>>>>>> assume just based on your feelings. I would be very interested
>>>>>>>>>>>> in
>>>>>>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>>>>>>> make such a big change "seconds" before you cut the release.
>>>>>>>>>>> You are usually very good and careful when you do the releases.
>>>>>>>>>>>
>>>>>>>>>>> The ticket its not a blocker for the 2.7 release. And it was
>>>>>>>>>>> already
>>>>>>>>>>> scheduled for Camel 2.8.
>>>>>>>>>>> And in terms of OSGi you have to be extra careful and test it
>>>>>>>>>>> more
>>>>>>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>>>>>>> The OSGi tests runs at the end of the CI process and thus they
>>>>>>>>>>> are
>>>>>>>>>>> more prone to not be run due test failures in pre-existing
>>>>>>>>>>> components.
>>>>>>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>>>>>>> Hence its a good practice to also run those OSGi tests locally
>>>>>>>>>>> once
>>>>>>>>>>> in a while to ensure it works well.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Claus Ibsen
>>>>>>>>>> -----------------
>>>>>>>>>> FuseSource
>>>>>>>>>> Email: cibsen@fusesource.com
>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>> Twitter: davsclaus
>>>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>         http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>

Re: [PROPOSAL]

[Willem Jiang <wi...@gmail.com>]

Hi Andreas,

I updated the camel itest-osgi-karaf to use Pax-Exam 1.2.4, it looks 
like current pax-exam doesn't support the new features of Karaf-2.2.0.

As karaf stand feature has more than on Spring feature, it's hard to let 
the pax-exam to tell which version of feature it should load. So the 
Pax-Exam tests can't be started rightly.
Before upgrading to new version of Pax-Exam which fixed that issue, we 
can't run camel integration tests successfully.

I will check the karaf integration tests today, to see if there is other 
solution for this kind of issue.

Willem

On 3/15/11 10:31 PM, Andreas Pieber wrote:
> Hey Willem, JB,
>
> If I understand you correctly this problem should only affect 2.2.x
> branch but not the master. The problem should be, AFAIK that we use
> pax-exam 1.2.3 in karaf-2.2 which uses an old version of karaf. I'll
> upgrade 2.2.x to exam 1.2.4. Can you please check if this fixes your
> problems?
>
> Kind regards,
> Andreas
>
> On Tue, Mar 15, 2011 at 2:18 PM, Jean-Baptiste Onofré<jb...@nanthrax.net>  wrote:
>> Hi Willem,
>>
>> thanks for your tests.
>>
>> I'm gonna check your issue (I will discuss with you on IRC around that).
>>
>> Regards
>> JB
>>
>> On 03/15/2011 02:18 PM, Willem Jiang wrote:
>>>
>>> I just ran the itest-osgi-karaf with the latest patch, and found current
>>> PaxExam doesn't support to load two features with different versions or
>>> load the features from other features file, so current camel osgi
>>> integration tests doesn't work with the patched camel-feature.
>>>
>>> I'm not sure how the Karaf tests it feature file, maybe JB can help me
>>> resolve this kind of issue.
>>>
>>> As we may need to use new version of PaxExam to load the karaf 2.2.0
>>> features file, it will take some time for us to fix the tests. My
>>> suggestion is we ship the features which supports Karaf 2.1.4 as a
>>> verified feature, and leave the features of Karaf 2.2.0 as an experiment
>>> release.
>>> In Camel 2.8.0 we can drop the support of Karaf 2.1.4.
>>>
>>> Any thought?
>>>
>>>
>>> On 3/14/11 11:57 PM, Jean-Baptiste Onofré wrote:
>>>>
>>>> Agree Hadrian,
>>>>
>>>> I think it's more "logical" to have:
>>>> - Camel 2.7 supports only Karaf 2.2.x
>>>> - ServiceMix 4.4.0 (powered by Karaf 2.2.x) will ship Camel 2.7
>>>> - if users want to stay with Karaf 2.1.x, they have to use Camel 2.6
>>>>
>>>> It sounds like a good plan for me :)
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 03/14/2011 03:55 PM, Hadrian Zbarcea wrote:
>>>>>
>>>>> If that's the case, this looks to me like not very useful. I am not
>>>>> against it, but it seems like a nice to have unnecessary effort. Users
>>>>> can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility
>>>>> with so many technologies, like Java 1.5. and Spring 2.5.x, to me
>>>>> Karaf 2.1.x is just a drop in the bucket. That's of course based on
>>>>> the assumption that very few will use the deprecated 2.1.x in
>>>>> production. It takes weeks to months to roll a new version (of Camel
>>>>> or anything else) in production.
>>>>>
>>>>> My $0.02,
>>>>> Hadrian
>>>>>
>>>>>
>>>>> On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant
>>>>>> features descriptor, the main changes are:
>>>>>> - the name of the jetty feature and jetty version used
>>>>>> - the avoid of resolver
>>>>>>
>>>>>> I will add this feature descriptor patch.
>>>>>>
>>>>>> However, I think that for Camel 2.8, we have to "break" the Karaf
>>>>>> 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf
>>>>>> 2.1.x will go to deprecation soon :)
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>>>>>>
>>>>>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>>>>>> rightly.
>>>>>>>
>>>>>>> I think we can provide another Feature.xml file like we did in Camel
>>>>>>> 2.6.0 to support the spring 2.5.x.
>>>>>>> In this case we could just provide another Features.xml which supports
>>>>>>> the Karaf 2.1.4 etc.
>>>>>>>
>>>>>>> Willem
>>>>>>>
>>>>>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>>>>>>
>>>>>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>>>>>> compatibility with karaf 2.1.x will be broken at some point. There is
>>>>>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>>>>>> soon. If 2.8.0 is released much later, we give users something
>>>>>>>> that is
>>>>>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>>>>>> already anyway), but we could negatively impact smx 4.4.
>>>>>>>> Traditionally
>>>>>>>> during the Camel lifetime we played very nice with other communities,
>>>>>>>> especially those that rely directly on Camel.
>>>>>>>>
>>>>>>>> That said, my proposal is this:
>>>>>>>> 1. We keep Jean Baptiste's patch.
>>>>>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>>>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>>>>>> 3. We release Camel 2.7.0 either:
>>>>>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>>>>>> Claus); the only impact of the patch is using the new obr features in
>>>>>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>>>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>>>>>> release to the Karaf 2.1.5 release
>>>>>>>> b. after the Karaf 2.1.5 release
>>>>>>>>
>>>>>>>> Personally I am ok with either 3a or 3b opting slightly towards
>>>>>>>> 3a. If
>>>>>>>> you have other proposals or a preference please speak up. I hope
>>>>>>>> us to
>>>>>>>> be in position to make a decision early next week.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Hadrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> On Thursday, March 10, 2011, Christian
>>>>>>>>> Schneider<cs...@talend.com>  wrote:
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I think the same way as Claus. We should try to not add any
>>>>>>>>>> functional changes a few days before a release. That is the only
>>>>>>>>>> way
>>>>>>>>>> to make sure people have time to run their tests against the code
>>>>>>>>>> base to be released.
>>>>>>>>>> I was already hesitant to commit my patch for the servlet on
>>>>>>>>>> friday.
>>>>>>>>>>
>>>>>>>>>> So I think we have two options for the features.xml issue. If it is
>>>>>>>>>> really important for 2.7.0 we do a new release with it included in
>>>>>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>>>>>> perhaps with Willems fixes.
>>>>>>>>>
>>>>>>>>> Yeah as christian says i think we got two options.
>>>>>>>>> 1) re cut release without the features patch
>>>>>>>>> 2) apply the patch and postpone the release for a week or longer, to
>>>>>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>>>>>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by
>>>>>>>>> jean in
>>>>>>>>> the given jira ticket.
>>>>>>>>>
>>>>>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4
>>>>>>>>> which
>>>>>>>>> needs a camel with karaf 2.2 and that features patch. Although we
>>>>>>>>> are
>>>>>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>>>>>
>>>>>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>>>>>> without me policing.
>>>>>>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>>>>>>> either option.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So I think what we should do is define a code freeze some days
>>>>>>>>>> before a release. During this time we should only commit bug fixes
>>>>>>>>>> but not functional changes. In a less formal way we already do
>>>>>>>>>> this.
>>>>>>>>>> If we think this could slow down progress on the trunk then we
>>>>>>>>>> could
>>>>>>>>>> at this point create a branch for the release.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yeah we are usually good at having a slowdown up til the release is
>>>>>>>>> cut. This time we had five or more days, which was really good. The
>>>>>>>>> last major func. Change was that servlet improvements which imho
>>>>>>>>> is a
>>>>>>>>> very good improvement. After this we fixed all the maven
>>>>>>>>> archetypes so
>>>>>>>>> they are working again. Other than that its bug fixes and test fixes
>>>>>>>>> leading up till the cut time.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Christian
>>>>>>>>>>
>>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>>>>>> An: dev@camel.apache.org
>>>>>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>>>>>> Zbarcea<hz...@gmail.com>  wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I see now that Willem already reverted the patch, not clear why, I
>>>>>>>>>>> assume just based on your feelings. I would be very interested in
>>>>>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>>>>>> make such a big change "seconds" before you cut the release.
>>>>>>>>>> You are usually very good and careful when you do the releases.
>>>>>>>>>>
>>>>>>>>>> The ticket its not a blocker for the 2.7 release. And it was
>>>>>>>>>> already
>>>>>>>>>> scheduled for Camel 2.8.
>>>>>>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>>>>>>> more prone to not be run due test failures in pre-existing
>>>>>>>>>> components.
>>>>>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>>>>>> Hence its a good practice to also run those OSGi tests locally once
>>>>>>>>>> in a while to ensure it works well.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Claus Ibsen
>>>>>>>>> -----------------
>>>>>>>>> FuseSource
>>>>>>>>> Email: cibsen@fusesource.com
>>>>>>>>> Web: http://fusesource.com
>>>>>>>>> Twitter: davsclaus
>>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang

Re: [PROPOSAL]

[Andreas Pieber <an...@gmail.com>]

Hey Willem, JB,

If I understand you correctly this problem should only affect 2.2.x
branch but not the master. The problem should be, AFAIK that we use
pax-exam 1.2.3 in karaf-2.2 which uses an old version of karaf. I'll
upgrade 2.2.x to exam 1.2.4. Can you please check if this fixes your
problems?

Kind regards,
Andreas

On Tue, Mar 15, 2011 at 2:18 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Willem,
>
> thanks for your tests.
>
> I'm gonna check your issue (I will discuss with you on IRC around that).
>
> Regards
> JB
>
> On 03/15/2011 02:18 PM, Willem Jiang wrote:
>>
>> I just ran the itest-osgi-karaf with the latest patch, and found current
>> PaxExam doesn't support to load two features with different versions or
>> load the features from other features file, so current camel osgi
>> integration tests doesn't work with the patched camel-feature.
>>
>> I'm not sure how the Karaf tests it feature file, maybe JB can help me
>> resolve this kind of issue.
>>
>> As we may need to use new version of PaxExam to load the karaf 2.2.0
>> features file, it will take some time for us to fix the tests. My
>> suggestion is we ship the features which supports Karaf 2.1.4 as a
>> verified feature, and leave the features of Karaf 2.2.0 as an experiment
>> release.
>> In Camel 2.8.0 we can drop the support of Karaf 2.1.4.
>>
>> Any thought?
>>
>>
>> On 3/14/11 11:57 PM, Jean-Baptiste Onofré wrote:
>>>
>>> Agree Hadrian,
>>>
>>> I think it's more "logical" to have:
>>> - Camel 2.7 supports only Karaf 2.2.x
>>> - ServiceMix 4.4.0 (powered by Karaf 2.2.x) will ship Camel 2.7
>>> - if users want to stay with Karaf 2.1.x, they have to use Camel 2.6
>>>
>>> It sounds like a good plan for me :)
>>>
>>> Regards
>>> JB
>>>
>>> On 03/14/2011 03:55 PM, Hadrian Zbarcea wrote:
>>>>
>>>> If that's the case, this looks to me like not very useful. I am not
>>>> against it, but it seems like a nice to have unnecessary effort. Users
>>>> can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility
>>>> with so many technologies, like Java 1.5. and Spring 2.5.x, to me
>>>> Karaf 2.1.x is just a drop in the bucket. That's of course based on
>>>> the assumption that very few will use the deprecated 2.1.x in
>>>> production. It takes weeks to months to roll a new version (of Camel
>>>> or anything else) in production.
>>>>
>>>> My $0.02,
>>>> Hadrian
>>>>
>>>>
>>>> On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant
>>>>> features descriptor, the main changes are:
>>>>> - the name of the jetty feature and jetty version used
>>>>> - the avoid of resolver
>>>>>
>>>>> I will add this feature descriptor patch.
>>>>>
>>>>> However, I think that for Camel 2.8, we have to "break" the Karaf
>>>>> 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf
>>>>> 2.1.x will go to deprecation soon :)
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>>>>>
>>>>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>>>>> rightly.
>>>>>>
>>>>>> I think we can provide another Feature.xml file like we did in Camel
>>>>>> 2.6.0 to support the spring 2.5.x.
>>>>>> In this case we could just provide another Features.xml which supports
>>>>>> the Karaf 2.1.4 etc.
>>>>>>
>>>>>> Willem
>>>>>>
>>>>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>>>>>
>>>>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>>>>> compatibility with karaf 2.1.x will be broken at some point. There is
>>>>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>>>>> soon. If 2.8.0 is released much later, we give users something
>>>>>>> that is
>>>>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>>>>> already anyway), but we could negatively impact smx 4.4.
>>>>>>> Traditionally
>>>>>>> during the Camel lifetime we played very nice with other communities,
>>>>>>> especially those that rely directly on Camel.
>>>>>>>
>>>>>>> That said, my proposal is this:
>>>>>>> 1. We keep Jean Baptiste's patch.
>>>>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>>>>> 3. We release Camel 2.7.0 either:
>>>>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>>>>> Claus); the only impact of the patch is using the new obr features in
>>>>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>>>>> release to the Karaf 2.1.5 release
>>>>>>> b. after the Karaf 2.1.5 release
>>>>>>>
>>>>>>> Personally I am ok with either 3a or 3b opting slightly towards
>>>>>>> 3a. If
>>>>>>> you have other proposals or a preference please speak up. I hope
>>>>>>> us to
>>>>>>> be in position to make a decision early next week.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Hadrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> On Thursday, March 10, 2011, Christian
>>>>>>>> Schneider<cs...@talend.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I think the same way as Claus. We should try to not add any
>>>>>>>>> functional changes a few days before a release. That is the only
>>>>>>>>> way
>>>>>>>>> to make sure people have time to run their tests against the code
>>>>>>>>> base to be released.
>>>>>>>>> I was already hesitant to commit my patch for the servlet on
>>>>>>>>> friday.
>>>>>>>>>
>>>>>>>>> So I think we have two options for the features.xml issue. If it is
>>>>>>>>> really important for 2.7.0 we do a new release with it included in
>>>>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>>>>> perhaps with Willems fixes.
>>>>>>>>
>>>>>>>> Yeah as christian says i think we got two options.
>>>>>>>> 1) re cut release without the features patch
>>>>>>>> 2) apply the patch and postpone the release for a week or longer, to
>>>>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>>>>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by
>>>>>>>> jean in
>>>>>>>> the given jira ticket.
>>>>>>>>
>>>>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4
>>>>>>>> which
>>>>>>>> needs a camel with karaf 2.2 and that features patch. Although we
>>>>>>>> are
>>>>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>>>>
>>>>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>>>>> without me policing.
>>>>>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>>>>>> either option.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> So I think what we should do is define a code freeze some days
>>>>>>>>> before a release. During this time we should only commit bug fixes
>>>>>>>>> but not functional changes. In a less formal way we already do
>>>>>>>>> this.
>>>>>>>>> If we think this could slow down progress on the trunk then we
>>>>>>>>> could
>>>>>>>>> at this point create a branch for the release.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yeah we are usually good at having a slowdown up til the release is
>>>>>>>> cut. This time we had five or more days, which was really good. The
>>>>>>>> last major func. Change was that servlet improvements which imho
>>>>>>>> is a
>>>>>>>> very good improvement. After this we fixed all the maven
>>>>>>>> archetypes so
>>>>>>>> they are working again. Other than that its bug fixes and test fixes
>>>>>>>> leading up till the cut time.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>>>>> An: dev@camel.apache.org
>>>>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>>>>
>>>>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>>>>> Zbarcea<hz...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I see now that Willem already reverted the patch, not clear why, I
>>>>>>>>>> assume just based on your feelings. I would be very interested in
>>>>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>>>>> make such a big change "seconds" before you cut the release.
>>>>>>>>> You are usually very good and careful when you do the releases.
>>>>>>>>>
>>>>>>>>> The ticket its not a blocker for the 2.7 release. And it was
>>>>>>>>> already
>>>>>>>>> scheduled for Camel 2.8.
>>>>>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>>>>>> more prone to not be run due test failures in pre-existing
>>>>>>>>> components.
>>>>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>>>>> Hence its a good practice to also run those OSGi tests locally once
>>>>>>>>> in a while to ensure it works well.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Claus Ibsen
>>>>>>>> -----------------
>>>>>>>> FuseSource
>>>>>>>> Email: cibsen@fusesource.com
>>>>>>>> Web: http://fusesource.com
>>>>>>>> Twitter: davsclaus
>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>

Re: [PROPOSAL]

[Hadrian Zbarcea <hz...@gmail.com>]

I am ready to start the 2.7.0 release builds. All pending issues seem resolved to everybody's satisfaction. The last hudson builds were also clean so we are in good shape.
If you know of any reason to delay the builds please shout now. I am doing a final smoke test now and will start the builds at around 12 pm edt.

Cheers,
Hadrian

On Mar 16, 2011, at 11:46 AM, Hadrian Zbarcea wrote:

> As per Willem's recommendation and previous proposal made by Christian, I will give this one more day for testing and will build the new 2.7.0 release candidate tomorrow morning.
> 
> Please delay your commits until the release is out (unless there is an obvious, important bug fix)
> 
> Thanks,
> Hadrian
> 
> 
> On Mar 16, 2011, at 5:23 AM, Willem Jiang wrote:
> 
>> Hi
>> 
>> I just committed the patch that JB provided with some modification.
>> Now the feature file can be validated with Karaf feature plugin.
>> Since there is no quick solution for us to fix the OSGi integration tests with the new camel karaf feature in few days, and there is no much changes in the camel karaf feature.
>> 
>> I suppose we fix the OSGi tests to Camel 2.8.0, in the mean time we can let the camel 2.7.0 out ASAP.
>> 
>> Willem
>> 
>> On 3/15/11 9:18 PM, Jean-Baptiste Onofré wrote:
>>> Hi Willem,
>>> 
>>> thanks for your tests.
>>> 
>>> I'm gonna check your issue (I will discuss with you on IRC around that).
>>> 
>>> Regards
>>> JB
>>> 
>>> On 03/15/2011 02:18 PM, Willem Jiang wrote:
>>>> I just ran the itest-osgi-karaf with the latest patch, and found current
>>>> PaxExam doesn't support to load two features with different versions or
>>>> load the features from other features file, so current camel osgi
>>>> integration tests doesn't work with the patched camel-feature.
>>>> 
>>>> I'm not sure how the Karaf tests it feature file, maybe JB can help me
>>>> resolve this kind of issue.
>>>> 
>>>> As we may need to use new version of PaxExam to load the karaf 2.2.0
>>>> features file, it will take some time for us to fix the tests. My
>>>> suggestion is we ship the features which supports Karaf 2.1.4 as a
>>>> verified feature, and leave the features of Karaf 2.2.0 as an experiment
>>>> release.
>>>> In Camel 2.8.0 we can drop the support of Karaf 2.1.4.
>>>> 
>>>> Any thought?
>>>> 
>>>> 
>>>> On 3/14/11 11:57 PM, Jean-Baptiste Onofré wrote:
>>>>> Agree Hadrian,
>>>>> 
>>>>> I think it's more "logical" to have:
>>>>> - Camel 2.7 supports only Karaf 2.2.x
>>>>> - ServiceMix 4.4.0 (powered by Karaf 2.2.x) will ship Camel 2.7
>>>>> - if users want to stay with Karaf 2.1.x, they have to use Camel 2.6
>>>>> 
>>>>> It sounds like a good plan for me :)
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>> On 03/14/2011 03:55 PM, Hadrian Zbarcea wrote:
>>>>>> If that's the case, this looks to me like not very useful. I am not
>>>>>> against it, but it seems like a nice to have unnecessary effort. Users
>>>>>> can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility
>>>>>> with so many technologies, like Java 1.5. and Spring 2.5.x, to me
>>>>>> Karaf 2.1.x is just a drop in the bucket. That's of course based on
>>>>>> the assumption that very few will use the deprecated 2.1.x in
>>>>>> production. It takes weeks to months to roll a new version (of Camel
>>>>>> or anything else) in production.
>>>>>> 
>>>>>> My $0.02,
>>>>>> Hadrian
>>>>>> 
>>>>>> 
>>>>>> On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant
>>>>>>> features descriptor, the main changes are:
>>>>>>> - the name of the jetty feature and jetty version used
>>>>>>> - the avoid of resolver
>>>>>>> 
>>>>>>> I will add this feature descriptor patch.
>>>>>>> 
>>>>>>> However, I think that for Camel 2.8, we have to "break" the Karaf
>>>>>>> 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf
>>>>>>> 2.1.x will go to deprecation soon :)
>>>>>>> 
>>>>>>> Regards
>>>>>>> JB
>>>>>>> 
>>>>>>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>>>>>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>>>>>>> rightly.
>>>>>>>> 
>>>>>>>> I think we can provide another Feature.xml file like we did in Camel
>>>>>>>> 2.6.0 to support the spring 2.5.x.
>>>>>>>> In this case we could just provide another Features.xml which
>>>>>>>> supports
>>>>>>>> the Karaf 2.1.4 etc.
>>>>>>>> 
>>>>>>>> Willem
>>>>>>>> 
>>>>>>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>>>>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>>>>>>> compatibility with karaf 2.1.x will be broken at some point.
>>>>>>>>> There is
>>>>>>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>>>>>>> soon. If 2.8.0 is released much later, we give users something
>>>>>>>>> that is
>>>>>>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>>>>>>> already anyway), but we could negatively impact smx 4.4.
>>>>>>>>> Traditionally
>>>>>>>>> during the Camel lifetime we played very nice with other
>>>>>>>>> communities,
>>>>>>>>> especially those that rely directly on Camel.
>>>>>>>>> 
>>>>>>>>> That said, my proposal is this:
>>>>>>>>> 1. We keep Jean Baptiste's patch.
>>>>>>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>>>>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>>>>>>> 3. We release Camel 2.7.0 either:
>>>>>>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>>>>>>> Claus); the only impact of the patch is using the new obr
>>>>>>>>> features in
>>>>>>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>>>>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>>>>>>> release to the Karaf 2.1.5 release
>>>>>>>>> b. after the Karaf 2.1.5 release
>>>>>>>>> 
>>>>>>>>> Personally I am ok with either 3a or 3b opting slightly towards
>>>>>>>>> 3a. If
>>>>>>>>> you have other proposals or a preference please speak up. I hope
>>>>>>>>> us to
>>>>>>>>> be in position to make a decision early next week.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Hadrian
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>>>>>> 
>>>>>>>>>> Hi
>>>>>>>>>> 
>>>>>>>>>> On Thursday, March 10, 2011, Christian
>>>>>>>>>> Schneider<cs...@talend.com> wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>> 
>>>>>>>>>>> I think the same way as Claus. We should try to not add any
>>>>>>>>>>> functional changes a few days before a release. That is the only
>>>>>>>>>>> way
>>>>>>>>>>> to make sure people have time to run their tests against the code
>>>>>>>>>>> base to be released.
>>>>>>>>>>> I was already hesitant to commit my patch for the servlet on
>>>>>>>>>>> friday.
>>>>>>>>>>> 
>>>>>>>>>>> So I think we have two options for the features.xml issue. If
>>>>>>>>>>> it is
>>>>>>>>>>> really important for 2.7.0 we do a new release with it included in
>>>>>>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>>>>>>> perhaps with Willems fixes.
>>>>>>>>>> 
>>>>>>>>>> Yeah as christian says i think we got two options.
>>>>>>>>>> 1) re cut release without the features patch
>>>>>>>>>> 2) apply the patch and postpone the release for a week or
>>>>>>>>>> longer, to
>>>>>>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also
>>>>>>>>>> mean
>>>>>>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by
>>>>>>>>>> jean in
>>>>>>>>>> the given jira ticket.
>>>>>>>>>> 
>>>>>>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4
>>>>>>>>>> which
>>>>>>>>>> needs a camel with karaf 2.2 and that features patch. Although we
>>>>>>>>>> are
>>>>>>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>>>>>> 
>>>>>>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>>>>>>> without me policing.
>>>>>>>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>>>>>>>> either option.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> So I think what we should do is define a code freeze some days
>>>>>>>>>>> before a release. During this time we should only commit bug fixes
>>>>>>>>>>> but not functional changes. In a less formal way we already do
>>>>>>>>>>> this.
>>>>>>>>>>> If we think this could slow down progress on the trunk then we
>>>>>>>>>>> could
>>>>>>>>>>> at this point create a branch for the release.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Yeah we are usually good at having a slowdown up til the release is
>>>>>>>>>> cut. This time we had five or more days, which was really good. The
>>>>>>>>>> last major func. Change was that servlet improvements which imho
>>>>>>>>>> is a
>>>>>>>>>> very good improvement. After this we fixed all the maven
>>>>>>>>>> archetypes so
>>>>>>>>>> they are working again. Other than that its bug fixes and test
>>>>>>>>>> fixes
>>>>>>>>>> leading up till the cut time.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Christian
>>>>>>>>>>> 
>>>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>>>>>>> An: dev@camel.apache.org
>>>>>>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>>>>>>> Zbarcea<hz...@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I see now that Willem already reverted the patch, not clear
>>>>>>>>>>>> why, I
>>>>>>>>>>>> assume just based on your feelings. I would be very interested in
>>>>>>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>>>>>>> make such a big change "seconds" before you cut the release.
>>>>>>>>>>> You are usually very good and careful when you do the releases.
>>>>>>>>>>> 
>>>>>>>>>>> The ticket its not a blocker for the 2.7 release. And it was
>>>>>>>>>>> already
>>>>>>>>>>> scheduled for Camel 2.8.
>>>>>>>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>>>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>>>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>>>>>>>> more prone to not be run due test failures in pre-existing
>>>>>>>>>>> components.
>>>>>>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>>>>>>> Hence its a good practice to also run those OSGi tests locally
>>>>>>>>>>> once
>>>>>>>>>>> in a while to ensure it works well.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Claus Ibsen
>>>>>>>>>> -----------------
>>>>>>>>>> FuseSource
>>>>>>>>>> Email: cibsen@fusesource.com
>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>> Twitter: davsclaus
>>>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> -- 
>> Willem
>> ----------------------------------
>> FuseSource
>> Web: http://www.fusesource.com
>> Blog:    http://willemjiang.blogspot.com (English)
>>        http://jnn.javaeye.com (Chinese)
>> Twitter: willemjiang
> 

Re: [PROPOSAL]

[Hadrian Zbarcea <hz...@gmail.com>]

As per Willem's recommendation and previous proposal made by Christian, I will give this one more day for testing and will build the new 2.7.0 release candidate tomorrow morning.

Please delay your commits until the release is out (unless there is an obvious, important bug fix)

Thanks,
Hadrian


On Mar 16, 2011, at 5:23 AM, Willem Jiang wrote:

> Hi
> 
> I just committed the patch that JB provided with some modification.
> Now the feature file can be validated with Karaf feature plugin.
> Since there is no quick solution for us to fix the OSGi integration tests with the new camel karaf feature in few days, and there is no much changes in the camel karaf feature.
> 
> I suppose we fix the OSGi tests to Camel 2.8.0, in the mean time we can let the camel 2.7.0 out ASAP.
> 
> Willem
> 
> On 3/15/11 9:18 PM, Jean-Baptiste Onofré wrote:
>> Hi Willem,
>> 
>> thanks for your tests.
>> 
>> I'm gonna check your issue (I will discuss with you on IRC around that).
>> 
>> Regards
>> JB
>> 
>> On 03/15/2011 02:18 PM, Willem Jiang wrote:
>>> I just ran the itest-osgi-karaf with the latest patch, and found current
>>> PaxExam doesn't support to load two features with different versions or
>>> load the features from other features file, so current camel osgi
>>> integration tests doesn't work with the patched camel-feature.
>>> 
>>> I'm not sure how the Karaf tests it feature file, maybe JB can help me
>>> resolve this kind of issue.
>>> 
>>> As we may need to use new version of PaxExam to load the karaf 2.2.0
>>> features file, it will take some time for us to fix the tests. My
>>> suggestion is we ship the features which supports Karaf 2.1.4 as a
>>> verified feature, and leave the features of Karaf 2.2.0 as an experiment
>>> release.
>>> In Camel 2.8.0 we can drop the support of Karaf 2.1.4.
>>> 
>>> Any thought?
>>> 
>>> 
>>> On 3/14/11 11:57 PM, Jean-Baptiste Onofré wrote:
>>>> Agree Hadrian,
>>>> 
>>>> I think it's more "logical" to have:
>>>> - Camel 2.7 supports only Karaf 2.2.x
>>>> - ServiceMix 4.4.0 (powered by Karaf 2.2.x) will ship Camel 2.7
>>>> - if users want to stay with Karaf 2.1.x, they have to use Camel 2.6
>>>> 
>>>> It sounds like a good plan for me :)
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>> On 03/14/2011 03:55 PM, Hadrian Zbarcea wrote:
>>>>> If that's the case, this looks to me like not very useful. I am not
>>>>> against it, but it seems like a nice to have unnecessary effort. Users
>>>>> can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility
>>>>> with so many technologies, like Java 1.5. and Spring 2.5.x, to me
>>>>> Karaf 2.1.x is just a drop in the bucket. That's of course based on
>>>>> the assumption that very few will use the deprecated 2.1.x in
>>>>> production. It takes weeks to months to roll a new version (of Camel
>>>>> or anything else) in production.
>>>>> 
>>>>> My $0.02,
>>>>> Hadrian
>>>>> 
>>>>> 
>>>>> On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant
>>>>>> features descriptor, the main changes are:
>>>>>> - the name of the jetty feature and jetty version used
>>>>>> - the avoid of resolver
>>>>>> 
>>>>>> I will add this feature descriptor patch.
>>>>>> 
>>>>>> However, I think that for Camel 2.8, we have to "break" the Karaf
>>>>>> 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf
>>>>>> 2.1.x will go to deprecation soon :)
>>>>>> 
>>>>>> Regards
>>>>>> JB
>>>>>> 
>>>>>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>>>>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>>>>>> rightly.
>>>>>>> 
>>>>>>> I think we can provide another Feature.xml file like we did in Camel
>>>>>>> 2.6.0 to support the spring 2.5.x.
>>>>>>> In this case we could just provide another Features.xml which
>>>>>>> supports
>>>>>>> the Karaf 2.1.4 etc.
>>>>>>> 
>>>>>>> Willem
>>>>>>> 
>>>>>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>>>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>>>>>> compatibility with karaf 2.1.x will be broken at some point.
>>>>>>>> There is
>>>>>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>>>>>> soon. If 2.8.0 is released much later, we give users something
>>>>>>>> that is
>>>>>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>>>>>> already anyway), but we could negatively impact smx 4.4.
>>>>>>>> Traditionally
>>>>>>>> during the Camel lifetime we played very nice with other
>>>>>>>> communities,
>>>>>>>> especially those that rely directly on Camel.
>>>>>>>> 
>>>>>>>> That said, my proposal is this:
>>>>>>>> 1. We keep Jean Baptiste's patch.
>>>>>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>>>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>>>>>> 3. We release Camel 2.7.0 either:
>>>>>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>>>>>> Claus); the only impact of the patch is using the new obr
>>>>>>>> features in
>>>>>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>>>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>>>>>> release to the Karaf 2.1.5 release
>>>>>>>> b. after the Karaf 2.1.5 release
>>>>>>>> 
>>>>>>>> Personally I am ok with either 3a or 3b opting slightly towards
>>>>>>>> 3a. If
>>>>>>>> you have other proposals or a preference please speak up. I hope
>>>>>>>> us to
>>>>>>>> be in position to make a decision early next week.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Hadrian
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>>>>> 
>>>>>>>>> Hi
>>>>>>>>> 
>>>>>>>>> On Thursday, March 10, 2011, Christian
>>>>>>>>> Schneider<cs...@talend.com> wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>> 
>>>>>>>>>> I think the same way as Claus. We should try to not add any
>>>>>>>>>> functional changes a few days before a release. That is the only
>>>>>>>>>> way
>>>>>>>>>> to make sure people have time to run their tests against the code
>>>>>>>>>> base to be released.
>>>>>>>>>> I was already hesitant to commit my patch for the servlet on
>>>>>>>>>> friday.
>>>>>>>>>> 
>>>>>>>>>> So I think we have two options for the features.xml issue. If
>>>>>>>>>> it is
>>>>>>>>>> really important for 2.7.0 we do a new release with it included in
>>>>>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>>>>>> perhaps with Willems fixes.
>>>>>>>>> 
>>>>>>>>> Yeah as christian says i think we got two options.
>>>>>>>>> 1) re cut release without the features patch
>>>>>>>>> 2) apply the patch and postpone the release for a week or
>>>>>>>>> longer, to
>>>>>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also
>>>>>>>>> mean
>>>>>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by
>>>>>>>>> jean in
>>>>>>>>> the given jira ticket.
>>>>>>>>> 
>>>>>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4
>>>>>>>>> which
>>>>>>>>> needs a camel with karaf 2.2 and that features patch. Although we
>>>>>>>>> are
>>>>>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>>>>> 
>>>>>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>>>>>> without me policing.
>>>>>>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>>>>>>> either option.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> So I think what we should do is define a code freeze some days
>>>>>>>>>> before a release. During this time we should only commit bug fixes
>>>>>>>>>> but not functional changes. In a less formal way we already do
>>>>>>>>>> this.
>>>>>>>>>> If we think this could slow down progress on the trunk then we
>>>>>>>>>> could
>>>>>>>>>> at this point create a branch for the release.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Yeah we are usually good at having a slowdown up til the release is
>>>>>>>>> cut. This time we had five or more days, which was really good. The
>>>>>>>>> last major func. Change was that servlet improvements which imho
>>>>>>>>> is a
>>>>>>>>> very good improvement. After this we fixed all the maven
>>>>>>>>> archetypes so
>>>>>>>>> they are working again. Other than that its bug fixes and test
>>>>>>>>> fixes
>>>>>>>>> leading up till the cut time.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Christian
>>>>>>>>>> 
>>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>>>>>> An: dev@camel.apache.org
>>>>>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>>>>> 
>>>>>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>>>>>> Zbarcea<hz...@gmail.com> wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I see now that Willem already reverted the patch, not clear
>>>>>>>>>>> why, I
>>>>>>>>>>> assume just based on your feelings. I would be very interested in
>>>>>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>>>>>> make such a big change "seconds" before you cut the release.
>>>>>>>>>> You are usually very good and careful when you do the releases.
>>>>>>>>>> 
>>>>>>>>>> The ticket its not a blocker for the 2.7 release. And it was
>>>>>>>>>> already
>>>>>>>>>> scheduled for Camel 2.8.
>>>>>>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>>>>>>> more prone to not be run due test failures in pre-existing
>>>>>>>>>> components.
>>>>>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>>>>>> Hence its a good practice to also run those OSGi tests locally
>>>>>>>>>> once
>>>>>>>>>> in a while to ensure it works well.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Claus Ibsen
>>>>>>>>> -----------------
>>>>>>>>> FuseSource
>>>>>>>>> Email: cibsen@fusesource.com
>>>>>>>>> Web: http://fusesource.com
>>>>>>>>> Twitter: davsclaus
>>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 
> -- 
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>         http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang

Re: [PROPOSAL]

[Willem Jiang <wi...@gmail.com>]

Hi

I just committed the patch that JB provided with some modification.
Now the feature file can be validated with Karaf feature plugin.
Since there is no quick solution for us to fix the OSGi integration 
tests with the new camel karaf feature in few days, and there is no much 
changes in the camel karaf feature.

I suppose we fix the OSGi tests to Camel 2.8.0, in the mean time we can 
let the camel 2.7.0 out ASAP.

Willem

On 3/15/11 9:18 PM, Jean-Baptiste Onofré wrote:
> Hi Willem,
>
> thanks for your tests.
>
> I'm gonna check your issue (I will discuss with you on IRC around that).
>
> Regards
> JB
>
> On 03/15/2011 02:18 PM, Willem Jiang wrote:
>> I just ran the itest-osgi-karaf with the latest patch, and found current
>> PaxExam doesn't support to load two features with different versions or
>> load the features from other features file, so current camel osgi
>> integration tests doesn't work with the patched camel-feature.
>>
>> I'm not sure how the Karaf tests it feature file, maybe JB can help me
>> resolve this kind of issue.
>>
>> As we may need to use new version of PaxExam to load the karaf 2.2.0
>> features file, it will take some time for us to fix the tests. My
>> suggestion is we ship the features which supports Karaf 2.1.4 as a
>> verified feature, and leave the features of Karaf 2.2.0 as an experiment
>> release.
>> In Camel 2.8.0 we can drop the support of Karaf 2.1.4.
>>
>> Any thought?
>>
>>
>> On 3/14/11 11:57 PM, Jean-Baptiste Onofré wrote:
>>> Agree Hadrian,
>>>
>>> I think it's more "logical" to have:
>>> - Camel 2.7 supports only Karaf 2.2.x
>>> - ServiceMix 4.4.0 (powered by Karaf 2.2.x) will ship Camel 2.7
>>> - if users want to stay with Karaf 2.1.x, they have to use Camel 2.6
>>>
>>> It sounds like a good plan for me :)
>>>
>>> Regards
>>> JB
>>>
>>> On 03/14/2011 03:55 PM, Hadrian Zbarcea wrote:
>>>> If that's the case, this looks to me like not very useful. I am not
>>>> against it, but it seems like a nice to have unnecessary effort. Users
>>>> can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility
>>>> with so many technologies, like Java 1.5. and Spring 2.5.x, to me
>>>> Karaf 2.1.x is just a drop in the bucket. That's of course based on
>>>> the assumption that very few will use the deprecated 2.1.x in
>>>> production. It takes weeks to months to roll a new version (of Camel
>>>> or anything else) in production.
>>>>
>>>> My $0.02,
>>>> Hadrian
>>>>
>>>>
>>>> On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant
>>>>> features descriptor, the main changes are:
>>>>> - the name of the jetty feature and jetty version used
>>>>> - the avoid of resolver
>>>>>
>>>>> I will add this feature descriptor patch.
>>>>>
>>>>> However, I think that for Camel 2.8, we have to "break" the Karaf
>>>>> 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf
>>>>> 2.1.x will go to deprecation soon :)
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>>>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>>>>> rightly.
>>>>>>
>>>>>> I think we can provide another Feature.xml file like we did in Camel
>>>>>> 2.6.0 to support the spring 2.5.x.
>>>>>> In this case we could just provide another Features.xml which
>>>>>> supports
>>>>>> the Karaf 2.1.4 etc.
>>>>>>
>>>>>> Willem
>>>>>>
>>>>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>>>>> compatibility with karaf 2.1.x will be broken at some point.
>>>>>>> There is
>>>>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>>>>> soon. If 2.8.0 is released much later, we give users something
>>>>>>> that is
>>>>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>>>>> already anyway), but we could negatively impact smx 4.4.
>>>>>>> Traditionally
>>>>>>> during the Camel lifetime we played very nice with other
>>>>>>> communities,
>>>>>>> especially those that rely directly on Camel.
>>>>>>>
>>>>>>> That said, my proposal is this:
>>>>>>> 1. We keep Jean Baptiste's patch.
>>>>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>>>>> 3. We release Camel 2.7.0 either:
>>>>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>>>>> Claus); the only impact of the patch is using the new obr
>>>>>>> features in
>>>>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>>>>> release to the Karaf 2.1.5 release
>>>>>>> b. after the Karaf 2.1.5 release
>>>>>>>
>>>>>>> Personally I am ok with either 3a or 3b opting slightly towards
>>>>>>> 3a. If
>>>>>>> you have other proposals or a preference please speak up. I hope
>>>>>>> us to
>>>>>>> be in position to make a decision early next week.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Hadrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> On Thursday, March 10, 2011, Christian
>>>>>>>> Schneider<cs...@talend.com> wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I think the same way as Claus. We should try to not add any
>>>>>>>>> functional changes a few days before a release. That is the only
>>>>>>>>> way
>>>>>>>>> to make sure people have time to run their tests against the code
>>>>>>>>> base to be released.
>>>>>>>>> I was already hesitant to commit my patch for the servlet on
>>>>>>>>> friday.
>>>>>>>>>
>>>>>>>>> So I think we have two options for the features.xml issue. If
>>>>>>>>> it is
>>>>>>>>> really important for 2.7.0 we do a new release with it included in
>>>>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>>>>> perhaps with Willems fixes.
>>>>>>>>
>>>>>>>> Yeah as christian says i think we got two options.
>>>>>>>> 1) re cut release without the features patch
>>>>>>>> 2) apply the patch and postpone the release for a week or
>>>>>>>> longer, to
>>>>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also
>>>>>>>> mean
>>>>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by
>>>>>>>> jean in
>>>>>>>> the given jira ticket.
>>>>>>>>
>>>>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4
>>>>>>>> which
>>>>>>>> needs a camel with karaf 2.2 and that features patch. Although we
>>>>>>>> are
>>>>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>>>>
>>>>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>>>>> without me policing.
>>>>>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>>>>>> either option.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> So I think what we should do is define a code freeze some days
>>>>>>>>> before a release. During this time we should only commit bug fixes
>>>>>>>>> but not functional changes. In a less formal way we already do
>>>>>>>>> this.
>>>>>>>>> If we think this could slow down progress on the trunk then we
>>>>>>>>> could
>>>>>>>>> at this point create a branch for the release.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yeah we are usually good at having a slowdown up til the release is
>>>>>>>> cut. This time we had five or more days, which was really good. The
>>>>>>>> last major func. Change was that servlet improvements which imho
>>>>>>>> is a
>>>>>>>> very good improvement. After this we fixed all the maven
>>>>>>>> archetypes so
>>>>>>>> they are working again. Other than that its bug fixes and test
>>>>>>>> fixes
>>>>>>>> leading up till the cut time.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>>>>> An: dev@camel.apache.org
>>>>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>>>>
>>>>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>>>>> Zbarcea<hz...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I see now that Willem already reverted the patch, not clear
>>>>>>>>>> why, I
>>>>>>>>>> assume just based on your feelings. I would be very interested in
>>>>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>>>>> make such a big change "seconds" before you cut the release.
>>>>>>>>> You are usually very good and careful when you do the releases.
>>>>>>>>>
>>>>>>>>> The ticket its not a blocker for the 2.7 release. And it was
>>>>>>>>> already
>>>>>>>>> scheduled for Camel 2.8.
>>>>>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>>>>>> more prone to not be run due test failures in pre-existing
>>>>>>>>> components.
>>>>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>>>>> Hence its a good practice to also run those OSGi tests locally
>>>>>>>>> once
>>>>>>>>> in a while to ensure it works well.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Claus Ibsen
>>>>>>>> -----------------
>>>>>>>> FuseSource
>>>>>>>> Email: cibsen@fusesource.com
>>>>>>>> Web: http://fusesource.com
>>>>>>>> Twitter: davsclaus
>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang

Re: [PROPOSAL]

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Willem,

thanks for your tests.

I'm gonna check your issue (I will discuss with you on IRC around that).

Regards
JB

On 03/15/2011 02:18 PM, Willem Jiang wrote:
> I just ran the itest-osgi-karaf with the latest patch, and found current
> PaxExam doesn't support to load two features with different versions or
> load the features from other features file, so current camel osgi
> integration tests doesn't work with the patched camel-feature.
>
> I'm not sure how the Karaf tests it feature file, maybe JB can help me
> resolve this kind of issue.
>
> As we may need to use new version of PaxExam to load the karaf 2.2.0
> features file, it will take some time for us to fix the tests. My
> suggestion is we ship the features which supports Karaf 2.1.4 as a
> verified feature, and leave the features of Karaf 2.2.0 as an experiment
> release.
> In Camel 2.8.0 we can drop the support of Karaf 2.1.4.
>
> Any thought?
>
>
> On 3/14/11 11:57 PM, Jean-Baptiste Onofré wrote:
>> Agree Hadrian,
>>
>> I think it's more "logical" to have:
>> - Camel 2.7 supports only Karaf 2.2.x
>> - ServiceMix 4.4.0 (powered by Karaf 2.2.x) will ship Camel 2.7
>> - if users want to stay with Karaf 2.1.x, they have to use Camel 2.6
>>
>> It sounds like a good plan for me :)
>>
>> Regards
>> JB
>>
>> On 03/14/2011 03:55 PM, Hadrian Zbarcea wrote:
>>> If that's the case, this looks to me like not very useful. I am not
>>> against it, but it seems like a nice to have unnecessary effort. Users
>>> can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility
>>> with so many technologies, like Java 1.5. and Spring 2.5.x, to me
>>> Karaf 2.1.x is just a drop in the bucket. That's of course based on
>>> the assumption that very few will use the deprecated 2.1.x in
>>> production. It takes weeks to months to roll a new version (of Camel
>>> or anything else) in production.
>>>
>>> My $0.02,
>>> Hadrian
>>>
>>>
>>> On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:
>>>
>>>> Hi,
>>>>
>>>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant
>>>> features descriptor, the main changes are:
>>>> - the name of the jetty feature and jetty version used
>>>> - the avoid of resolver
>>>>
>>>> I will add this feature descriptor patch.
>>>>
>>>> However, I think that for Camel 2.8, we have to "break" the Karaf
>>>> 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf
>>>> 2.1.x will go to deprecation soon :)
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>>>> rightly.
>>>>>
>>>>> I think we can provide another Feature.xml file like we did in Camel
>>>>> 2.6.0 to support the spring 2.5.x.
>>>>> In this case we could just provide another Features.xml which supports
>>>>> the Karaf 2.1.4 etc.
>>>>>
>>>>> Willem
>>>>>
>>>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>>>> compatibility with karaf 2.1.x will be broken at some point. There is
>>>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>>>> soon. If 2.8.0 is released much later, we give users something
>>>>>> that is
>>>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>>>> already anyway), but we could negatively impact smx 4.4.
>>>>>> Traditionally
>>>>>> during the Camel lifetime we played very nice with other communities,
>>>>>> especially those that rely directly on Camel.
>>>>>>
>>>>>> That said, my proposal is this:
>>>>>> 1. We keep Jean Baptiste's patch.
>>>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>>>> 3. We release Camel 2.7.0 either:
>>>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>>>> Claus); the only impact of the patch is using the new obr features in
>>>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>>>> release to the Karaf 2.1.5 release
>>>>>> b. after the Karaf 2.1.5 release
>>>>>>
>>>>>> Personally I am ok with either 3a or 3b opting slightly towards
>>>>>> 3a. If
>>>>>> you have other proposals or a preference please speak up. I hope
>>>>>> us to
>>>>>> be in position to make a decision early next week.
>>>>>>
>>>>>> Thanks,
>>>>>> Hadrian
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> On Thursday, March 10, 2011, Christian
>>>>>>> Schneider<cs...@talend.com> wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I think the same way as Claus. We should try to not add any
>>>>>>>> functional changes a few days before a release. That is the only
>>>>>>>> way
>>>>>>>> to make sure people have time to run their tests against the code
>>>>>>>> base to be released.
>>>>>>>> I was already hesitant to commit my patch for the servlet on
>>>>>>>> friday.
>>>>>>>>
>>>>>>>> So I think we have two options for the features.xml issue. If it is
>>>>>>>> really important for 2.7.0 we do a new release with it included in
>>>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>>>> perhaps with Willems fixes.
>>>>>>>
>>>>>>> Yeah as christian says i think we got two options.
>>>>>>> 1) re cut release without the features patch
>>>>>>> 2) apply the patch and postpone the release for a week or longer, to
>>>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>>>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by
>>>>>>> jean in
>>>>>>> the given jira ticket.
>>>>>>>
>>>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4
>>>>>>> which
>>>>>>> needs a camel with karaf 2.2 and that features patch. Although we
>>>>>>> are
>>>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>>>
>>>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>>>> without me policing.
>>>>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>>>>> either option.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> So I think what we should do is define a code freeze some days
>>>>>>>> before a release. During this time we should only commit bug fixes
>>>>>>>> but not functional changes. In a less formal way we already do
>>>>>>>> this.
>>>>>>>> If we think this could slow down progress on the trunk then we
>>>>>>>> could
>>>>>>>> at this point create a branch for the release.
>>>>>>>>
>>>>>>>
>>>>>>> Yeah we are usually good at having a slowdown up til the release is
>>>>>>> cut. This time we had five or more days, which was really good. The
>>>>>>> last major func. Change was that servlet improvements which imho
>>>>>>> is a
>>>>>>> very good improvement. After this we fixed all the maven
>>>>>>> archetypes so
>>>>>>> they are working again. Other than that its bug fixes and test fixes
>>>>>>> leading up till the cut time.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>>>> An: dev@camel.apache.org
>>>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>>>
>>>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>>>> Zbarcea<hz...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I see now that Willem already reverted the patch, not clear why, I
>>>>>>>>> assume just based on your feelings. I would be very interested in
>>>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>>>> make such a big change "seconds" before you cut the release.
>>>>>>>> You are usually very good and careful when you do the releases.
>>>>>>>>
>>>>>>>> The ticket its not a blocker for the 2.7 release. And it was
>>>>>>>> already
>>>>>>>> scheduled for Camel 2.8.
>>>>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>>>>> more prone to not be run due test failures in pre-existing
>>>>>>>> components.
>>>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>>>> Hence its a good practice to also run those OSGi tests locally once
>>>>>>>> in a while to ensure it works well.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> -----------------
>>>>>>> FuseSource
>>>>>>> Email: cibsen@fusesource.com
>>>>>>> Web: http://fusesource.com
>>>>>>> Twitter: davsclaus
>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>
>

Re: [PROPOSAL]

[Willem Jiang <wi...@gmail.com>]

I just ran the itest-osgi-karaf with the latest patch, and found current 
PaxExam doesn't support to load two features with different versions or 
load the features from other features file, so current camel osgi 
integration tests doesn't work with the patched camel-feature.

I'm not sure how the Karaf tests it feature file, maybe JB can help me 
resolve this kind of issue.

As we may need to use new version of PaxExam to load the karaf 2.2.0 
features file, it will take some time for us to fix the tests. My 
suggestion is we ship the features which supports Karaf 2.1.4 as a 
verified feature, and leave the features of Karaf 2.2.0 as an experiment 
release.
In Camel 2.8.0 we can drop the support of Karaf 2.1.4.

Any thought?


On 3/14/11 11:57 PM, Jean-Baptiste Onofré wrote:
> Agree Hadrian,
>
> I think it's more "logical" to have:
> - Camel 2.7 supports only Karaf 2.2.x
> - ServiceMix 4.4.0 (powered by Karaf 2.2.x) will ship Camel 2.7
> - if users want to stay with Karaf 2.1.x, they have to use Camel 2.6
>
> It sounds like a good plan for me :)
>
> Regards
> JB
>
> On 03/14/2011 03:55 PM, Hadrian Zbarcea wrote:
>> If that's the case, this looks to me like not very useful. I am not
>> against it, but it seems like a nice to have unnecessary effort. Users
>> can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility
>> with so many technologies, like Java 1.5. and Spring 2.5.x, to me
>> Karaf 2.1.x is just a drop in the bucket. That's of course based on
>> the assumption that very few will use the deprecated 2.1.x in
>> production. It takes weeks to months to roll a new version (of Camel
>> or anything else) in production.
>>
>> My $0.02,
>> Hadrian
>>
>>
>> On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:
>>
>>> Hi,
>>>
>>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant
>>> features descriptor, the main changes are:
>>> - the name of the jetty feature and jetty version used
>>> - the avoid of resolver
>>>
>>> I will add this feature descriptor patch.
>>>
>>> However, I think that for Camel 2.8, we have to "break" the Karaf
>>> 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf
>>> 2.1.x will go to deprecation soon :)
>>>
>>> Regards
>>> JB
>>>
>>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>>> rightly.
>>>>
>>>> I think we can provide another Feature.xml file like we did in Camel
>>>> 2.6.0 to support the spring 2.5.x.
>>>> In this case we could just provide another Features.xml which supports
>>>> the Karaf 2.1.4 etc.
>>>>
>>>> Willem
>>>>
>>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>>> compatibility with karaf 2.1.x will be broken at some point. There is
>>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>>> soon. If 2.8.0 is released much later, we give users something that is
>>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>>> already anyway), but we could negatively impact smx 4.4. Traditionally
>>>>> during the Camel lifetime we played very nice with other communities,
>>>>> especially those that rely directly on Camel.
>>>>>
>>>>> That said, my proposal is this:
>>>>> 1. We keep Jean Baptiste's patch.
>>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>>> 3. We release Camel 2.7.0 either:
>>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>>> Claus); the only impact of the patch is using the new obr features in
>>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>>> release to the Karaf 2.1.5 release
>>>>> b. after the Karaf 2.1.5 release
>>>>>
>>>>> Personally I am ok with either 3a or 3b opting slightly towards 3a. If
>>>>> you have other proposals or a preference please speak up. I hope us to
>>>>> be in position to make a decision early next week.
>>>>>
>>>>> Thanks,
>>>>> Hadrian
>>>>>
>>>>>
>>>>>
>>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Thursday, March 10, 2011, Christian
>>>>>> Schneider<cs...@talend.com> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I think the same way as Claus. We should try to not add any
>>>>>>> functional changes a few days before a release. That is the only way
>>>>>>> to make sure people have time to run their tests against the code
>>>>>>> base to be released.
>>>>>>> I was already hesitant to commit my patch for the servlet on friday.
>>>>>>>
>>>>>>> So I think we have two options for the features.xml issue. If it is
>>>>>>> really important for 2.7.0 we do a new release with it included in
>>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>>> perhaps with Willems fixes.
>>>>>>
>>>>>> Yeah as christian says i think we got two options.
>>>>>> 1) re cut release without the features patch
>>>>>> 2) apply the patch and postpone the release for a week or longer, to
>>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by
>>>>>> jean in
>>>>>> the given jira ticket.
>>>>>>
>>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>>>>>> needs a camel with karaf 2.2 and that features patch. Although we are
>>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>>
>>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>>> without me policing.
>>>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>>>> either option.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> So I think what we should do is define a code freeze some days
>>>>>>> before a release. During this time we should only commit bug fixes
>>>>>>> but not functional changes. In a less formal way we already do this.
>>>>>>> If we think this could slow down progress on the trunk then we could
>>>>>>> at this point create a branch for the release.
>>>>>>>
>>>>>>
>>>>>> Yeah we are usually good at having a slowdown up til the release is
>>>>>> cut. This time we had five or more days, which was really good. The
>>>>>> last major func. Change was that servlet improvements which imho is a
>>>>>> very good improvement. After this we fixed all the maven
>>>>>> archetypes so
>>>>>> they are working again. Other than that its bug fixes and test fixes
>>>>>> leading up till the cut time.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>>> An: dev@camel.apache.org
>>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>>
>>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>>> Zbarcea<hz...@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I see now that Willem already reverted the patch, not clear why, I
>>>>>>>> assume just based on your feelings. I would be very interested in
>>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>>
>>>>>>>
>>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>>> make such a big change "seconds" before you cut the release.
>>>>>>> You are usually very good and careful when you do the releases.
>>>>>>>
>>>>>>> The ticket its not a blocker for the 2.7 release. And it was already
>>>>>>> scheduled for Camel 2.8.
>>>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>>>> more prone to not be run due test failures in pre-existing
>>>>>>> components.
>>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>>> Hence its a good practice to also run those OSGi tests locally once
>>>>>>> in a while to ensure it works well.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> -----------------
>>>>>> FuseSource
>>>>>> Email: cibsen@fusesource.com
>>>>>> Web: http://fusesource.com
>>>>>> Twitter: davsclaus
>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>
>>>>>
>>>>
>>>>
>>
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang

Re: [PROPOSAL]

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Agree Hadrian,

I think it's more "logical" to have:
- Camel 2.7 supports only Karaf 2.2.x
- ServiceMix 4.4.0 (powered by Karaf 2.2.x) will ship Camel 2.7
- if users want to stay with Karaf 2.1.x, they have to use Camel 2.6

It sounds like a good plan for me :)

Regards
JB

On 03/14/2011 03:55 PM, Hadrian Zbarcea wrote:
> If that's the case, this looks to me like not very useful. I am not against it, but it seems like a nice to have unnecessary effort. Users can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility with so many technologies, like Java 1.5. and Spring 2.5.x, to me Karaf 2.1.x is just a drop in the bucket. That's of course based on the assumption that very few will use the deprecated 2.1.x in production. It takes weeks to months to roll a new version (of Camel or anything else) in production.
>
> My $0.02,
> Hadrian
>
>
> On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:
>
>> Hi,
>>
>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant features descriptor, the main changes are:
>> - the name of the jetty feature and jetty version used
>> - the avoid of resolver
>>
>> I will add this feature descriptor patch.
>>
>> However, I think that for Camel 2.8, we have to "break" the Karaf 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf 2.1.x will go to deprecation soon :)
>>
>> Regards
>> JB
>>
>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>> rightly.
>>>
>>> I think we can provide another Feature.xml file like we did in Camel
>>> 2.6.0 to support the spring 2.5.x.
>>> In this case we could just provide another Features.xml which supports
>>> the Karaf 2.1.4 etc.
>>>
>>> Willem
>>>
>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>> compatibility with karaf 2.1.x will be broken at some point. There is
>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>> soon. If 2.8.0 is released much later, we give users something that is
>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>> already anyway), but we could negatively impact smx 4.4. Traditionally
>>>> during the Camel lifetime we played very nice with other communities,
>>>> especially those that rely directly on Camel.
>>>>
>>>> That said, my proposal is this:
>>>> 1. We keep Jean Baptiste's patch.
>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>> 3. We release Camel 2.7.0 either:
>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>> Claus); the only impact of the patch is using the new obr features in
>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>> release to the Karaf 2.1.5 release
>>>> b. after the Karaf 2.1.5 release
>>>>
>>>> Personally I am ok with either 3a or 3b opting slightly towards 3a. If
>>>> you have other proposals or a preference please speak up. I hope us to
>>>> be in position to make a decision early next week.
>>>>
>>>> Thanks,
>>>> Hadrian
>>>>
>>>>
>>>>
>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Thursday, March 10, 2011, Christian
>>>>> Schneider<cs...@talend.com>  wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I think the same way as Claus. We should try to not add any
>>>>>> functional changes a few days before a release. That is the only way
>>>>>> to make sure people have time to run their tests against the code
>>>>>> base to be released.
>>>>>> I was already hesitant to commit my patch for the servlet on friday.
>>>>>>
>>>>>> So I think we have two options for the features.xml issue. If it is
>>>>>> really important for 2.7.0 we do a new release with it included in
>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>> perhaps with Willems fixes.
>>>>>
>>>>> Yeah as christian says i think we got two options.
>>>>> 1) re cut release without the features patch
>>>>> 2) apply the patch and postpone the release for a week or longer, to
>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
>>>>> the given jira ticket.
>>>>>
>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>>>>> needs a camel with karaf 2.2 and that features patch. Although we are
>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>
>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>> without me policing.
>>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>>> either option.
>>>>>
>>>>>
>>>>>>
>>>>>> So I think what we should do is define a code freeze some days
>>>>>> before a release. During this time we should only commit bug fixes
>>>>>> but not functional changes. In a less formal way we already do this.
>>>>>> If we think this could slow down progress on the trunk then we could
>>>>>> at this point create a branch for the release.
>>>>>>
>>>>>
>>>>> Yeah we are usually good at having a slowdown up til the release is
>>>>> cut. This time we had five or more days, which was really good. The
>>>>> last major func. Change was that servlet improvements which imho is a
>>>>> very good improvement. After this we fixed all the maven archetypes so
>>>>> they are working again. Other than that its bug fixes and test fixes
>>>>> leading up till the cut time.
>>>>>
>>>>>
>>>>>
>>>>>> Christian
>>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>> An: dev@camel.apache.org
>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>
>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>> Zbarcea<hz...@gmail.com>  wrote:
>>>>>>
>>>>>>>
>>>>>>> I see now that Willem already reverted the patch, not clear why, I
>>>>>>> assume just based on your feelings. I would be very interested in
>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>
>>>>>>
>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>> make such a big change "seconds" before you cut the release.
>>>>>> You are usually very good and careful when you do the releases.
>>>>>>
>>>>>> The ticket its not a blocker for the 2.7 release. And it was already
>>>>>> scheduled for Camel 2.8.
>>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>>> more prone to not be run due test failures in pre-existing components.
>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>> Hence its a good practice to also run those OSGi tests locally once
>>>>>> in a while to ensure it works well.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> FuseSource
>>>>> Email: cibsen@fusesource.com
>>>>> Web: http://fusesource.com
>>>>> Twitter: davsclaus
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>
>>>>
>>>
>>>
>

Re: [PROPOSAL]

[Claus Ibsen <cl...@gmail.com>]

On Mon, Mar 14, 2011 at 3:55 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> If that's the case, this looks to me like not very useful. I am not against it, but it seems like a nice to have unnecessary effort. Users can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility with so many technologies, like Java 1.5. and Spring 2.5.x, to me Karaf 2.1.x is just a drop in the bucket. That's of course based on the assumption that very few will use the deprecated 2.1.x in production. It takes weeks to months to roll a new version (of Camel or anything else) in production.
>
> My $0.02,
> Hadrian
>

Yeah I kinda agree with Hadrian. We might as well just bite the bullet
and say that Camel 2.7+ requires Karaf 2.2.x+.
In light of Karaf 2.1.x is being deprecated, and the fact that SMX 4.4
is using Karaf 2.2.0 and want to use Camel 2.7.

So anything that makes maintenance and testing easier for the Camel
project is a +1 for me. We already got 100+ artifacts to test and the
OSGi tests is also time consuming to run and keep being green.

And as Hadrian pointed out, the Camel 2.7 is a big change for
JDK/spring/logger and whatnot. So why not also put Karaf in that
basket as well.


>
> On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:
>
>> Hi,
>>
>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant features descriptor, the main changes are:
>> - the name of the jetty feature and jetty version used
>> - the avoid of resolver
>>
>> I will add this feature descriptor patch.
>>
>> However, I think that for Camel 2.8, we have to "break" the Karaf 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf 2.1.x will go to deprecation soon :)
>>
>> Regards
>> JB
>>
>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>> rightly.
>>>
>>> I think we can provide another Feature.xml file like we did in Camel
>>> 2.6.0 to support the spring 2.5.x.
>>> In this case we could just provide another Features.xml which supports
>>> the Karaf 2.1.4 etc.
>>>
>>> Willem
>>>
>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>> compatibility with karaf 2.1.x will be broken at some point. There is
>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>> soon. If 2.8.0 is released much later, we give users something that is
>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>> already anyway), but we could negatively impact smx 4.4. Traditionally
>>>> during the Camel lifetime we played very nice with other communities,
>>>> especially those that rely directly on Camel.
>>>>
>>>> That said, my proposal is this:
>>>> 1. We keep Jean Baptiste's patch.
>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>> 3. We release Camel 2.7.0 either:
>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>> Claus); the only impact of the patch is using the new obr features in
>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>> release to the Karaf 2.1.5 release
>>>> b. after the Karaf 2.1.5 release
>>>>
>>>> Personally I am ok with either 3a or 3b opting slightly towards 3a. If
>>>> you have other proposals or a preference please speak up. I hope us to
>>>> be in position to make a decision early next week.
>>>>
>>>> Thanks,
>>>> Hadrian
>>>>
>>>>
>>>>
>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Thursday, March 10, 2011, Christian
>>>>> Schneider<cs...@talend.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I think the same way as Claus. We should try to not add any
>>>>>> functional changes a few days before a release. That is the only way
>>>>>> to make sure people have time to run their tests against the code
>>>>>> base to be released.
>>>>>> I was already hesitant to commit my patch for the servlet on friday.
>>>>>>
>>>>>> So I think we have two options for the features.xml issue. If it is
>>>>>> really important for 2.7.0 we do a new release with it included in
>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>> perhaps with Willems fixes.
>>>>>
>>>>> Yeah as christian says i think we got two options.
>>>>> 1) re cut release without the features patch
>>>>> 2) apply the patch and postpone the release for a week or longer, to
>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
>>>>> the given jira ticket.
>>>>>
>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>>>>> needs a camel with karaf 2.2 and that features patch. Although we are
>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>
>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>> without me policing.
>>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>>> either option.
>>>>>
>>>>>
>>>>>>
>>>>>> So I think what we should do is define a code freeze some days
>>>>>> before a release. During this time we should only commit bug fixes
>>>>>> but not functional changes. In a less formal way we already do this.
>>>>>> If we think this could slow down progress on the trunk then we could
>>>>>> at this point create a branch for the release.
>>>>>>
>>>>>
>>>>> Yeah we are usually good at having a slowdown up til the release is
>>>>> cut. This time we had five or more days, which was really good. The
>>>>> last major func. Change was that servlet improvements which imho is a
>>>>> very good improvement. After this we fixed all the maven archetypes so
>>>>> they are working again. Other than that its bug fixes and test fixes
>>>>> leading up till the cut time.
>>>>>
>>>>>
>>>>>
>>>>>> Christian
>>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>> An: dev@camel.apache.org
>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>
>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>> Zbarcea<hz...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> I see now that Willem already reverted the patch, not clear why, I
>>>>>>> assume just based on your feelings. I would be very interested in
>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>
>>>>>>
>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>> make such a big change "seconds" before you cut the release.
>>>>>> You are usually very good and careful when you do the releases.
>>>>>>
>>>>>> The ticket its not a blocker for the 2.7 release. And it was already
>>>>>> scheduled for Camel 2.8.
>>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>>> more prone to not be run due test failures in pre-existing components.
>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>> Hence its a good practice to also run those OSGi tests locally once
>>>>>> in a while to ensure it works well.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> FuseSource
>>>>> Email: cibsen@fusesource.com
>>>>> Web: http://fusesource.com
>>>>> Twitter: davsclaus
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>
>>>>
>>>
>>>
>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [PROPOSAL]

[Hadrian Zbarcea <hz...@gmail.com>]

If that's the case, this looks to me like not very useful. I am not against it, but it seems like a nice to have unnecessary effort. Users can use 2.6.0 with karaf 2.1.x. Since in 2.7.0 we break compatibility with so many technologies, like Java 1.5. and Spring 2.5.x, to me Karaf 2.1.x is just a drop in the bucket. That's of course based on the assumption that very few will use the deprecated 2.1.x in production. It takes weeks to months to roll a new version (of Camel or anything else) in production.

My $0.02,
Hadrian


On Mar 13, 2011, at 3:41 AM, Jean-Baptiste Onofré wrote:

> Hi,
> 
> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant features descriptor, the main changes are:
> - the name of the jetty feature and jetty version used
> - the avoid of resolver
> 
> I will add this feature descriptor patch.
> 
> However, I think that for Camel 2.8, we have to "break" the Karaf 2.1.x compatibility. Karaf 2.2.0 is now the stable release, Karaf 2.1.x will go to deprecation soon :)
> 
> Regards
> JB
> 
> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>> +1 for the 3.a, and we need to make sure the Feature file is working
>> rightly.
>> 
>> I think we can provide another Feature.xml file like we did in Camel
>> 2.6.0 to support the spring 2.5.x.
>> In this case we could just provide another Features.xml which supports
>> the Karaf 2.1.4 etc.
>> 
>> Willem
>> 
>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>> compatibility with karaf 2.1.x will be broken at some point. There is
>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>> soon. If 2.8.0 is released much later, we give users something that is
>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>> already anyway), but we could negatively impact smx 4.4. Traditionally
>>> during the Camel lifetime we played very nice with other communities,
>>> especially those that rely directly on Camel.
>>> 
>>> That said, my proposal is this:
>>> 1. We keep Jean Baptiste's patch.
>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>> next Karaf 2.1.5 the compatibility will be restored.
>>> 3. We release Camel 2.7.0 either:
>>> a. after a few days of testing (per Christian proposal, +1'd by
>>> Claus); the only impact of the patch is using the new obr features in
>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>> release to the Karaf 2.1.5 release
>>> b. after the Karaf 2.1.5 release
>>> 
>>> Personally I am ok with either 3a or 3b opting slightly towards 3a. If
>>> you have other proposals or a preference please speak up. I hope us to
>>> be in position to make a decision early next week.
>>> 
>>> Thanks,
>>> Hadrian
>>> 
>>> 
>>> 
>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>> 
>>>> Hi
>>>> 
>>>> On Thursday, March 10, 2011, Christian
>>>> Schneider<cs...@talend.com> wrote:
>>>>> Hi all,
>>>>> 
>>>>> I think the same way as Claus. We should try to not add any
>>>>> functional changes a few days before a release. That is the only way
>>>>> to make sure people have time to run their tests against the code
>>>>> base to be released.
>>>>> I was already hesitant to commit my patch for the servlet on friday.
>>>>> 
>>>>> So I think we have two options for the features.xml issue. If it is
>>>>> really important for 2.7.0 we do a new release with it included in
>>>>> some days. If not we cut a release now with the reverted version,
>>>>> perhaps with Willems fixes.
>>>> 
>>>> Yeah as christian says i think we got two options.
>>>> 1) re cut release without the features patch
>>>> 2) apply the patch and postpone the release for a week or longer, to
>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
>>>> the given jira ticket.
>>>> 
>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>>>> needs a camel with karaf 2.2 and that features patch. Although we are
>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>> 
>>>> I am traveling for the next two weeks, so you guys can have fun
>>>> without me policing.
>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>> either option.
>>>> 
>>>> 
>>>>> 
>>>>> So I think what we should do is define a code freeze some days
>>>>> before a release. During this time we should only commit bug fixes
>>>>> but not functional changes. In a less formal way we already do this.
>>>>> If we think this could slow down progress on the trunk then we could
>>>>> at this point create a branch for the release.
>>>>> 
>>>> 
>>>> Yeah we are usually good at having a slowdown up til the release is
>>>> cut. This time we had five or more days, which was really good. The
>>>> last major func. Change was that servlet improvements which imho is a
>>>> very good improvement. After this we fixed all the maven archetypes so
>>>> they are working again. Other than that its bug fixes and test fixes
>>>> leading up till the cut time.
>>>> 
>>>> 
>>>> 
>>>>> Christian
>>>>> 
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>> An: dev@camel.apache.org
>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>> 
>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>> Zbarcea<hz...@gmail.com> wrote:
>>>>> 
>>>>>> 
>>>>>> I see now that Willem already reverted the patch, not clear why, I
>>>>>> assume just based on your feelings. I would be very interested in
>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>> 
>>>>> 
>>>>> I really dont understand why you would think its "no brainer" to
>>>>> make such a big change "seconds" before you cut the release.
>>>>> You are usually very good and careful when you do the releases.
>>>>> 
>>>>> The ticket its not a blocker for the 2.7 release. And it was already
>>>>> scheduled for Camel 2.8.
>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>> more prone to not be run due test failures in pre-existing components.
>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>> Hence its a good practice to also run those OSGi tests locally once
>>>>> in a while to ensure it works well.
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> FuseSource
>>>> Email: cibsen@fusesource.com
>>>> Web: http://fusesource.com
>>>> Twitter: davsclaus
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>> 
>>> 
>> 
>> 

Re: [PROPOSAL]

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Claus,

Thanks for the update.

I will work on it with Willem.

I will keep you posted soon.

Regards
JB

On 03/14/2011 02:05 PM, Claus Ibsen wrote:
> On Sun, Mar 13, 2011 at 8:41 AM, Jean-Baptiste Onofré<jb...@nanthrax.net>  wrote:
>> Hi,
>>
>> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant features
>> descriptor, the main changes are:
>> - the name of the jetty feature and jetty version used
>> - the avoid of resolver
>>
>> I will add this feature descriptor patch.
>>
>> However, I think that for Camel 2.8, we have to "break" the Karaf 2.1.x
>> compatibility. Karaf 2.2.0 is now the stable release, Karaf 2.1.x will go to
>> deprecation soon :)
>>
>
> Thats pretty fast :)
>
> Anyway I just tried before traveling to
> - upgrade to use Karaf 2.2.0 in all the ogsi/karaf tests (without the
> features path) = FAIL
> - apply features patch and use Karaf 2.2.0 in all the osgi/karaf tests = FAIL
>
> So its not an easy upgrade. I did not look into it. Just applied the
> upgrade/patch and ran all the tests.
> I assume Willem and maybe Jean would help look into this to see what
> may be the issue.
>
>
> If we add a 2nd features file in Camel then I assume we do not want to
> maintain that for very long.
> We had 2 features files for Camel 2.0-2.6 to cater for spring 2/3. And
> frankly we would need to test with both feature files to ensure it
> works. So it would be nice to let the Karaf 2.1.x feature file be
> short lived if that makes sense?
>
>
>
>
>> Regards
>> JB
>>
>> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>>
>>> +1 for the 3.a, and we need to make sure the Feature file is working
>>> rightly.
>>>
>>> I think we can provide another Feature.xml file like we did in Camel
>>> 2.6.0 to support the spring 2.5.x.
>>> In this case we could just provide another Features.xml which supports
>>> the Karaf 2.1.4 etc.
>>>
>>> Willem
>>>
>>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>>
>>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>>> compatibility with karaf 2.1.x will be broken at some point. There is
>>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>>> soon. If 2.8.0 is released much later, we give users something that is
>>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>>> already anyway), but we could negatively impact smx 4.4. Traditionally
>>>> during the Camel lifetime we played very nice with other communities,
>>>> especially those that rely directly on Camel.
>>>>
>>>> That said, my proposal is this:
>>>> 1. We keep Jean Baptiste's patch.
>>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>>> next Karaf 2.1.5 the compatibility will be restored.
>>>> 3. We release Camel 2.7.0 either:
>>>> a. after a few days of testing (per Christian proposal, +1'd by
>>>> Claus); the only impact of the patch is using the new obr features in
>>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>>> release to the Karaf 2.1.5 release
>>>> b. after the Karaf 2.1.5 release
>>>>
>>>> Personally I am ok with either 3a or 3b opting slightly towards 3a. If
>>>> you have other proposals or a preference please speak up. I hope us to
>>>> be in position to make a decision early next week.
>>>>
>>>> Thanks,
>>>> Hadrian
>>>>
>>>>
>>>>
>>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Thursday, March 10, 2011, Christian
>>>>> Schneider<cs...@talend.com>  wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I think the same way as Claus. We should try to not add any
>>>>>> functional changes a few days before a release. That is the only way
>>>>>> to make sure people have time to run their tests against the code
>>>>>> base to be released.
>>>>>> I was already hesitant to commit my patch for the servlet on friday.
>>>>>>
>>>>>> So I think we have two options for the features.xml issue. If it is
>>>>>> really important for 2.7.0 we do a new release with it included in
>>>>>> some days. If not we cut a release now with the reverted version,
>>>>>> perhaps with Willems fixes.
>>>>>
>>>>> Yeah as christian says i think we got two options.
>>>>> 1) re cut release without the features patch
>>>>> 2) apply the patch and postpone the release for a week or longer, to
>>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
>>>>> the given jira ticket.
>>>>>
>>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>>>>> needs a camel with karaf 2.2 and that features patch. Although we are
>>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>>
>>>>> I am traveling for the next two weeks, so you guys can have fun
>>>>> without me policing.
>>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>>> either option.
>>>>>
>>>>>
>>>>>>
>>>>>> So I think what we should do is define a code freeze some days
>>>>>> before a release. During this time we should only commit bug fixes
>>>>>> but not functional changes. In a less formal way we already do this.
>>>>>> If we think this could slow down progress on the trunk then we could
>>>>>> at this point create a branch for the release.
>>>>>>
>>>>>
>>>>> Yeah we are usually good at having a slowdown up til the release is
>>>>> cut. This time we had five or more days, which was really good. The
>>>>> last major func. Change was that servlet improvements which imho is a
>>>>> very good improvement. After this we fixed all the maven archetypes so
>>>>> they are working again. Other than that its bug fixes and test fixes
>>>>> leading up till the cut time.
>>>>>
>>>>>
>>>>>
>>>>>> Christian
>>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>>> An: dev@camel.apache.org
>>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>>
>>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>>> Zbarcea<hz...@gmail.com>  wrote:
>>>>>>
>>>>>>>
>>>>>>> I see now that Willem already reverted the patch, not clear why, I
>>>>>>> assume just based on your feelings. I would be very interested in
>>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>>
>>>>>>
>>>>>> I really dont understand why you would think its "no brainer" to
>>>>>> make such a big change "seconds" before you cut the release.
>>>>>> You are usually very good and careful when you do the releases.
>>>>>>
>>>>>> The ticket its not a blocker for the 2.7 release. And it was already
>>>>>> scheduled for Camel 2.8.
>>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>>> more prone to not be run due test failures in pre-existing components.
>>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>>> Hence its a good practice to also run those OSGi tests locally once
>>>>>> in a while to ensure it works well.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> FuseSource
>>>>> Email: cibsen@fusesource.com
>>>>> Web: http://fusesource.com
>>>>> Twitter: davsclaus
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>
>>>>
>>>
>>>
>>
>
>
>

Re: [PROPOSAL]

[Claus Ibsen <cl...@gmail.com>]

On Sun, Mar 13, 2011 at 8:41 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi,
>
> It could make sense for the Camel 2.7. For 2.1.x Karaf compliant features
> descriptor, the main changes are:
> - the name of the jetty feature and jetty version used
> - the avoid of resolver
>
> I will add this feature descriptor patch.
>
> However, I think that for Camel 2.8, we have to "break" the Karaf 2.1.x
> compatibility. Karaf 2.2.0 is now the stable release, Karaf 2.1.x will go to
> deprecation soon :)
>

Thats pretty fast :)

Anyway I just tried before traveling to
- upgrade to use Karaf 2.2.0 in all the ogsi/karaf tests (without the
features path) = FAIL
- apply features patch and use Karaf 2.2.0 in all the osgi/karaf tests = FAIL

So its not an easy upgrade. I did not look into it. Just applied the
upgrade/patch and ran all the tests.
I assume Willem and maybe Jean would help look into this to see what
may be the issue.


If we add a 2nd features file in Camel then I assume we do not want to
maintain that for very long.
We had 2 features files for Camel 2.0-2.6 to cater for spring 2/3. And
frankly we would need to test with both feature files to ensure it
works. So it would be nice to let the Karaf 2.1.x feature file be
short lived if that makes sense?




> Regards
> JB
>
> On 03/13/2011 07:50 AM, Willem Jiang wrote:
>>
>> +1 for the 3.a, and we need to make sure the Feature file is working
>> rightly.
>>
>> I think we can provide another Feature.xml file like we did in Camel
>> 2.6.0 to support the spring 2.5.x.
>> In this case we could just provide another Features.xml which supports
>> the Karaf 2.1.4 etc.
>>
>> Willem
>>
>> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>>>
>>> We knew this patch will go in, now or 2.8.0 which meant that the
>>> compatibility with karaf 2.1.x will be broken at some point. There is
>>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>>> soon. If 2.8.0 is released much later, we give users something that is
>>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>>> already anyway), but we could negatively impact smx 4.4. Traditionally
>>> during the Camel lifetime we played very nice with other communities,
>>> especially those that rely directly on Camel.
>>>
>>> That said, my proposal is this:
>>> 1. We keep Jean Baptiste's patch.
>>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>>> next Karaf 2.1.5 the compatibility will be restored.
>>> 3. We release Camel 2.7.0 either:
>>> a. after a few days of testing (per Christian proposal, +1'd by
>>> Claus); the only impact of the patch is using the new obr features in
>>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>>> impacts; this leaves a few weeks of incompatibility from the Camel
>>> release to the Karaf 2.1.5 release
>>> b. after the Karaf 2.1.5 release
>>>
>>> Personally I am ok with either 3a or 3b opting slightly towards 3a. If
>>> you have other proposals or a preference please speak up. I hope us to
>>> be in position to make a decision early next week.
>>>
>>> Thanks,
>>> Hadrian
>>>
>>>
>>>
>>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>>
>>>> Hi
>>>>
>>>> On Thursday, March 10, 2011, Christian
>>>> Schneider<cs...@talend.com> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I think the same way as Claus. We should try to not add any
>>>>> functional changes a few days before a release. That is the only way
>>>>> to make sure people have time to run their tests against the code
>>>>> base to be released.
>>>>> I was already hesitant to commit my patch for the servlet on friday.
>>>>>
>>>>> So I think we have two options for the features.xml issue. If it is
>>>>> really important for 2.7.0 we do a new release with it included in
>>>>> some days. If not we cut a release now with the reverted version,
>>>>> perhaps with Willems fixes.
>>>>
>>>> Yeah as christian says i think we got two options.
>>>> 1) re cut release without the features patch
>>>> 2) apply the patch and postpone the release for a week or longer, to
>>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
>>>> the given jira ticket.
>>>>
>>>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>>>> needs a camel with karaf 2.2 and that features patch. Although we are
>>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>>
>>>> I am traveling for the next two weeks, so you guys can have fun
>>>> without me policing.
>>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>>> either option.
>>>>
>>>>
>>>>>
>>>>> So I think what we should do is define a code freeze some days
>>>>> before a release. During this time we should only commit bug fixes
>>>>> but not functional changes. In a less formal way we already do this.
>>>>> If we think this could slow down progress on the trunk then we could
>>>>> at this point create a branch for the release.
>>>>>
>>>>
>>>> Yeah we are usually good at having a slowdown up til the release is
>>>> cut. This time we had five or more days, which was really good. The
>>>> last major func. Change was that servlet improvements which imho is a
>>>> very good improvement. After this we fixed all the maven archetypes so
>>>> they are working again. Other than that its bug fixes and test fixes
>>>> leading up till the cut time.
>>>>
>>>>
>>>>
>>>>> Christian
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>>> An: dev@camel.apache.org
>>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>>
>>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>>> Zbarcea<hz...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> I see now that Willem already reverted the patch, not clear why, I
>>>>>> assume just based on your feelings. I would be very interested in
>>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>>
>>>>>
>>>>> I really dont understand why you would think its "no brainer" to
>>>>> make such a big change "seconds" before you cut the release.
>>>>> You are usually very good and careful when you do the releases.
>>>>>
>>>>> The ticket its not a blocker for the 2.7 release. And it was already
>>>>> scheduled for Camel 2.8.
>>>>> And in terms of OSGi you have to be extra careful and test it more
>>>>> thoroughly than a simpler fix in a plain Camel component.
>>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>>> more prone to not be run due test failures in pre-existing components.
>>>>> We all know it can be a little tricky to have CI 100% green.
>>>>> Hence its a good practice to also run those OSGi tests locally once
>>>>> in a while to ensure it works well.
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> FuseSource
>>>> Email: cibsen@fusesource.com
>>>> Web: http://fusesource.com
>>>> Twitter: davsclaus
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>
>>>
>>
>>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [PROPOSAL]

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi,

It could make sense for the Camel 2.7. For 2.1.x Karaf compliant 
features descriptor, the main changes are:
- the name of the jetty feature and jetty version used
- the avoid of resolver

I will add this feature descriptor patch.

However, I think that for Camel 2.8, we have to "break" the Karaf 2.1.x 
compatibility. Karaf 2.2.0 is now the stable release, Karaf 2.1.x will 
go to deprecation soon :)

Regards
JB

On 03/13/2011 07:50 AM, Willem Jiang wrote:
> +1 for the 3.a, and we need to make sure the Feature file is working
> rightly.
>
> I think we can provide another Feature.xml file like we did in Camel
> 2.6.0 to support the spring 2.5.x.
> In this case we could just provide another Features.xml which supports
> the Karaf 2.1.4 etc.
>
> Willem
>
> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>> We knew this patch will go in, now or 2.8.0 which meant that the
>> compatibility with karaf 2.1.x will be broken at some point. There is
>> no real difference if we do it now or in 2.8.0 if 2.8.0 is released
>> soon. If 2.8.0 is released much later, we give users something that is
>> java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does
>> already anyway), but we could negatively impact smx 4.4. Traditionally
>> during the Camel lifetime we played very nice with other communities,
>> especially those that rely directly on Camel.
>>
>> That said, my proposal is this:
>> 1. We keep Jean Baptiste's patch.
>> 2. JB opened and KARAF-505 and will commit a patch soon. As of the
>> next Karaf 2.1.5 the compatibility will be restored.
>> 3. We release Camel 2.7.0 either:
>> a. after a few days of testing (per Christian proposal, +1'd by
>> Claus); the only impact of the patch is using the new obr features in
>> Karaf 2.2.0 (which was tested, contrary to allegations), no other
>> impacts; this leaves a few weeks of incompatibility from the Camel
>> release to the Karaf 2.1.5 release
>> b. after the Karaf 2.1.5 release
>>
>> Personally I am ok with either 3a or 3b opting slightly towards 3a. If
>> you have other proposals or a preference please speak up. I hope us to
>> be in position to make a decision early next week.
>>
>> Thanks,
>> Hadrian
>>
>>
>>
>> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>>
>>> Hi
>>>
>>> On Thursday, March 10, 2011, Christian
>>> Schneider<cs...@talend.com> wrote:
>>>> Hi all,
>>>>
>>>> I think the same way as Claus. We should try to not add any
>>>> functional changes a few days before a release. That is the only way
>>>> to make sure people have time to run their tests against the code
>>>> base to be released.
>>>> I was already hesitant to commit my patch for the servlet on friday.
>>>>
>>>> So I think we have two options for the features.xml issue. If it is
>>>> really important for 2.7.0 we do a new release with it included in
>>>> some days. If not we cut a release now with the reverted version,
>>>> perhaps with Willems fixes.
>>>
>>> Yeah as christian says i think we got two options.
>>> 1) re cut release without the features patch
>>> 2) apply the patch and postpone the release for a week or longer, to
>>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
>>> the given jira ticket.
>>>
>>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>>> needs a camel with karaf 2.2 and that features patch. Although we are
>>> very likely to be able to cut a new camel 2.8 release beforehand.
>>>
>>> I am traveling for the next two weeks, so you guys can have fun
>>> without me policing.
>>> In light of this and the fact smx 4,4 need the patch, i am okay for
>>> either option.
>>>
>>>
>>>>
>>>> So I think what we should do is define a code freeze some days
>>>> before a release. During this time we should only commit bug fixes
>>>> but not functional changes. In a less formal way we already do this.
>>>> If we think this could slow down progress on the trunk then we could
>>>> at this point create a branch for the release.
>>>>
>>>
>>> Yeah we are usually good at having a slowdown up til the release is
>>> cut. This time we had five or more days, which was really good. The
>>> last major func. Change was that servlet improvements which imho is a
>>> very good improvement. After this we fixed all the maven archetypes so
>>> they are working again. Other than that its bug fixes and test fixes
>>> leading up till the cut time.
>>>
>>>
>>>
>>>> Christian
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>>> An: dev@camel.apache.org
>>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>>
>>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian
>>>> Zbarcea<hz...@gmail.com> wrote:
>>>>
>>>>>
>>>>> I see now that Willem already reverted the patch, not clear why, I
>>>>> assume just based on your feelings. I would be very interested in
>>>>> seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>>
>>>>
>>>> I really dont understand why you would think its "no brainer" to
>>>> make such a big change "seconds" before you cut the release.
>>>> You are usually very good and careful when you do the releases.
>>>>
>>>> The ticket its not a blocker for the 2.7 release. And it was already
>>>> scheduled for Camel 2.8.
>>>> And in terms of OSGi you have to be extra careful and test it more
>>>> thoroughly than a simpler fix in a plain Camel component.
>>>> The OSGi tests runs at the end of the CI process and thus they are
>>>> more prone to not be run due test failures in pre-existing components.
>>>> We all know it can be a little tricky to have CI 100% green.
>>>> Hence its a good practice to also run those OSGi tests locally once
>>>> in a while to ensure it works well.
>>>>
>>>>
>>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> FuseSource
>>> Email: cibsen@fusesource.com
>>> Web: http://fusesource.com
>>> Twitter: davsclaus
>>> Blog: http://davsclaus.blogspot.com/
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
>>
>
>

Re: [PROPOSAL]

[Guillaume Nodet <gn...@gmail.com>]

That's actually a great suggestion and this would be even better imo.


Le dimanche 13 mars 2011, Willem Jiang <wi...@gmail.com> a écrit :
> +1 for the 3.a, and we need to make sure the Feature file is working rightly.
>
> I think we can provide another Feature.xml file like we did in Camel 2.6.0 to support the spring 2.5.x.
> In this case we could just provide another Features.xml which supports the Karaf 2.1.4 etc.
>
> Willem
>
> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>
> We knew this patch will go in, now or 2.8.0 which meant that the compatibility with karaf 2.1.x will be broken at some point. There is no real difference if we do it now or in 2.8.0 if 2.8.0 is released soon. If 2.8.0 is released much later, we give users something that is java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does already anyway), but we could negatively impact smx 4.4. Traditionally during the Camel lifetime we played very nice with other communities, especially those that rely directly on Camel.
>
> That said, my proposal is this:
> 1. We keep Jean Baptiste's patch.
> 2. JB opened and KARAF-505 and will commit a patch soon. As of the next Karaf 2.1.5 the compatibility will be restored.
> 3. We release Camel 2.7.0 either:
>   a. after a few days of testing (per Christian proposal, +1'd by Claus); the only impact of the patch is using the new obr features in Karaf 2.2.0 (which was tested, contrary to allegations), no other impacts; this leaves a few weeks of incompatibility from the Camel release to the Karaf 2.1.5 release
>   b. after the Karaf 2.1.5 release
>
> Personally I am ok with either 3a or 3b opting slightly towards 3a. If you have other proposals or a preference please speak up. I hope us to be in position to make a decision early next week.
>
> Thanks,
> Hadrian
>
>
>
> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>
>
> Hi
>
> On Thursday, March 10, 2011, Christian Schneider<cs...@talend.com>  wrote:
>
> Hi all,
>
> I think the same way as Claus. We should try to not add any functional changes a few days before a release. That is the only way to make sure people have time to run their tests against the code base to be released.
> I was already hesitant to commit my patch for the servlet on friday.
>
> So I think we have two options for the features.xml issue. If it is really important for 2.7.0 we do a new release with it included in some days. If not we cut a release now with the reverted version, perhaps with Willems fixes.
>
>
> Yeah as christian says i think we got two options.
> 1) re cut release without the features patch
> 2) apply the patch and postpone the release for a week or longer, to
> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
> the given jira ticket.
>
> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
> needs a camel with karaf 2.2 and that features patch. Although we are
> very likely to be able to cut a new camel 2.8 release beforehand.
>
> I am traveling for the next two weeks, so you guys can have fun
> without me policing.
> In light of this and the fact smx 4,4 need the patch, i am okay for
> either option.
>
>
>
>
> So I think what we should do is define a code freeze some days before a release. During this time we should only commit bug fixes but not functional changes. In a less formal way we already do this.
> If we think this could slow down progress on the trunk then we could at this point create a branch for the release.
>
>
>
> Yeah we are usually good at having a slowdown up til the release is
> cut. This time we had five or more days, which was really good. The
> last major func. Change was that servlet improvements which imho is a
> very good improvement. After this we fixed all the maven archetypes so
> they are working again. Other than that its bug fixes and test fixes
> leading up till the cut time.
>
>
>
>
> Christian
>
> -----Ursprüngliche Nachricht-----
> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Gesendet: Donnerstag, 10. März 2011 11:44
> An: dev@camel.apache.org
> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>
> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian Zbarcea<hz...@gmail.com>  wrote:
>
>
>
> I see now that Willem already reverted the patch, not clear why, I assume just based on your feelings. I would be very interested in seeing Guillaume's opinion, as a Karaf/OSGi expert.
>
>
>
> I really dont understand why you would think its "no brainer" to make such a big change "seconds" before you cut the release.
> You are usually very good and careful when you do the releases.
>
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>          http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>

-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: [PROPOSAL]

[Willem Jiang <wi...@gmail.com>]

+1 for the 3.a, and we need to make sure the Feature file is working 
rightly.

I think we can provide another Feature.xml file like we did in Camel 
2.6.0 to support the spring 2.5.x.
In this case we could just provide another Features.xml which supports 
the Karaf 2.1.4 etc.

Willem

On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
> We knew this patch will go in, now or 2.8.0 which meant that the compatibility with karaf 2.1.x will be broken at some point. There is no real difference if we do it now or in 2.8.0 if 2.8.0 is released soon. If 2.8.0 is released much later, we give users something that is java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does already anyway), but we could negatively impact smx 4.4. Traditionally during the Camel lifetime we played very nice with other communities, especially those that rely directly on Camel.
>
> That said, my proposal is this:
> 1. We keep Jean Baptiste's patch.
> 2. JB opened and KARAF-505 and will commit a patch soon. As of the next Karaf 2.1.5 the compatibility will be restored.
> 3. We release Camel 2.7.0 either:
>   a. after a few days of testing (per Christian proposal, +1'd by Claus); the only impact of the patch is using the new obr features in Karaf 2.2.0 (which was tested, contrary to allegations), no other impacts; this leaves a few weeks of incompatibility from the Camel release to the Karaf 2.1.5 release
>   b. after the Karaf 2.1.5 release
>
> Personally I am ok with either 3a or 3b opting slightly towards 3a. If you have other proposals or a preference please speak up. I hope us to be in position to make a decision early next week.
>
> Thanks,
> Hadrian
>
>
>
> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>
>> Hi
>>
>> On Thursday, March 10, 2011, Christian Schneider<cs...@talend.com>  wrote:
>>> Hi all,
>>>
>>> I think the same way as Claus. We should try to not add any functional changes a few days before a release. That is the only way to make sure people have time to run their tests against the code base to be released.
>>> I was already hesitant to commit my patch for the servlet on friday.
>>>
>>> So I think we have two options for the features.xml issue. If it is really important for 2.7.0 we do a new release with it included in some days. If not we cut a release now with the reverted version, perhaps with Willems fixes.
>>
>> Yeah as christian says i think we got two options.
>> 1) re cut release without the features patch
>> 2) apply the patch and postpone the release for a week or longer, to
>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
>> the given jira ticket.
>>
>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>> needs a camel with karaf 2.2 and that features patch. Although we are
>> very likely to be able to cut a new camel 2.8 release beforehand.
>>
>> I am traveling for the next two weeks, so you guys can have fun
>> without me policing.
>> In light of this and the fact smx 4,4 need the patch, i am okay for
>> either option.
>>
>>
>>>
>>> So I think what we should do is define a code freeze some days before a release. During this time we should only commit bug fixes but not functional changes. In a less formal way we already do this.
>>> If we think this could slow down progress on the trunk then we could at this point create a branch for the release.
>>>
>>
>> Yeah we are usually good at having a slowdown up til the release is
>> cut. This time we had five or more days, which was really good. The
>> last major func. Change was that servlet improvements which imho is a
>> very good improvement. After this we fixed all the maven archetypes so
>> they are working again. Other than that its bug fixes and test fixes
>> leading up till the cut time.
>>
>>
>>
>>> Christian
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>> An: dev@camel.apache.org
>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>
>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian Zbarcea<hz...@gmail.com>  wrote:
>>>
>>>>
>>>> I see now that Willem already reverted the patch, not clear why, I assume just based on your feelings. I would be very interested in seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>
>>>
>>> I really dont understand why you would think its "no brainer" to make such a big change "seconds" before you cut the release.
>>> You are usually very good and careful when you do the releases.
>>>
>>> The ticket its not a blocker for the 2.7 release. And it was already scheduled for Camel 2.8.
>>> And in terms of OSGi you have to be extra careful and test it more thoroughly than a simpler fix in a plain Camel component.
>>> The OSGi tests runs at the end of the CI process and thus they are more prone to not be run due test failures in pre-existing components.
>>> We all know it can be a little tricky to have CI 100% green.
>>> Hence its a good practice to also run those OSGi tests locally once in a while to ensure it works well.
>>>
>>>
>>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang

Re: [PROPOSAL]

[Christian Müller <ch...@gmail.com>]

+1 for 3a

Christian

Re: [PROPOSAL]

[Christian Schneider <ch...@die-schneider.net>]

3 a sounds good to me.

Christian

Am 11.03.2011 19:07, schrieb Hadrian Zbarcea:
> We knew this patch will go in, now or 2.8.0 which meant that the compatibility with karaf 2.1.x will be broken at some point. There is no real difference if we do it now or in 2.8.0 if 2.8.0 is released soon. If 2.8.0 is released much later, we give users something that is java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does already anyway), but we could negatively impact smx 4.4. Traditionally during the Camel lifetime we played very nice with other communities, especially those that rely directly on Camel.
>
> That said, my proposal is this:
> 1. We keep Jean Baptiste's patch.
> 2. JB opened and KARAF-505 and will commit a patch soon. As of the next Karaf 2.1.5 the compatibility will be restored.
> 3. We release Camel 2.7.0 either:
>   a. after a few days of testing (per Christian proposal, +1'd by Claus); the only impact of the patch is using the new obr features in Karaf 2.2.0 (which was tested, contrary to allegations), no other impacts; this leaves a few weeks of incompatibility from the Camel release to the Karaf 2.1.5 release
>   b. after the Karaf 2.1.5 release
>
> Personally I am ok with either 3a or 3b opting slightly towards 3a. If you have other proposals or a preference please speak up. I hope us to be in position to make a decision early next week.
>
> Thanks,
> Hadrian
>
>
>
> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>
>> Hi
>>
>> On Thursday, March 10, 2011, Christian Schneider<cs...@talend.com>  wrote:
>>> Hi all,
>>>
>>> I think the same way as Claus. We should try to not add any functional changes a few days before a release. That is the only way to make sure people have time to run their tests against the code base to be released.
>>> I was already hesitant to commit my patch for the servlet on friday.
>>>
>>> So I think we have two options for the features.xml issue. If it is really important for 2.7.0 we do a new release with it included in some days. If not we cut a release now with the reverted version, perhaps with Willems fixes.
>> Yeah as christian says i think we got two options.
>> 1) re cut release without the features patch
>> 2) apply the patch and postpone the release for a week or longer, to
>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
>> the given jira ticket.
>>
>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>> needs a camel with karaf 2.2 and that features patch. Although we are
>> very likely to be able to cut a new camel 2.8 release beforehand.
>>
>> I am traveling for the next two weeks, so you guys can have fun
>> without me policing.
>> In light of this and the fact smx 4,4 need the patch, i am okay for
>> either option.
>>
>>
>>> So I think what we should do is define a code freeze some days before a release. During this time we should only commit bug fixes but not functional changes. In a less formal way we already do this.
>>> If we think this could slow down progress on the trunk then we could at this point create a branch for the release.
>>>
>> Yeah we are usually good at having a slowdown up til the release is
>> cut. This time we had five or more days, which was really good. The
>> last major func. Change was that servlet improvements which imho is a
>> very good improvement. After this we fixed all the maven archetypes so
>> they are working again. Other than that its bug fixes and test fixes
>> leading up till the cut time.
>>
>>
>>
>>> Christian
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>> An: dev@camel.apache.org
>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>
>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian Zbarcea<hz...@gmail.com>  wrote:
>>>
>>>> I see now that Willem already reverted the patch, not clear why, I assume just based on your feelings. I would be very interested in seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>
>>> I really dont understand why you would think its "no brainer" to make such a big change "seconds" before you cut the release.
>>> You are usually very good and careful when you do the releases.
>>>
>>> The ticket its not a blocker for the 2.7 release. And it was already scheduled for Camel 2.8.
>>> And in terms of OSGi you have to be extra careful and test it more thoroughly than a simpler fix in a plain Camel component.
>>> The OSGi tests runs at the end of the CI process and thus they are more prone to not be run due test failures in pre-existing components.
>>> We all know it can be a little tricky to have CI 100% green.
>>> Hence its a good practice to also run those OSGi tests locally once in a while to ensure it works well.
>>>
>>>
>>>
>> -- 
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>

-- 
----
http://www.liquid-reality.de

Re: [PROPOSAL] (was: [VOTE] Release Apache Camel 2.7.0)

[Claus Ibsen <cl...@gmail.com>]

Hi

Thanks for posting a detailed and informative proposal for a plan.


On Fri, Mar 11, 2011 at 7:07 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> We knew this patch will go in, now or 2.8.0 which meant that the compatibility with karaf 2.1.x will be broken at some point. There is no real difference if we do it now or in 2.8.0 if 2.8.0 is released soon. If 2.8.0 is released much later, we give users something that is java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does already anyway), but we could negatively impact smx 4.4. Traditionally during the Camel lifetime we played very nice with other communities, especially those that rely directly on Camel.
>
> That said, my proposal is this:
> 1. We keep Jean Baptiste's patch.
> 2. JB opened and KARAF-505 and will commit a patch soon. As of the next Karaf 2.1.5 the compatibility will be restored.
> 3. We release Camel 2.7.0 either:
>  a. after a few days of testing (per Christian proposal, +1'd by Claus); the only impact of the patch is using the new obr features in Karaf 2.2.0 (which was tested, contrary to allegations), no other impacts; this leaves a few weeks of incompatibility from the Camel release to the Karaf 2.1.5 release
>  b. after the Karaf 2.1.5 release
>
> Personally I am ok with either 3a or 3b opting slightly towards 3a. If you have other proposals or a preference please speak up. I hope us to be in position to make a decision early next week.
>

I am +1 for 3a if we give it time to be tested, not only by CI
servers, but also that someone take time to manually test this in
Karaf 2.2.0, by deploying some Camel 2.7 features and see it works
there as well!

The unit tests in tests/xxx should be configured to use Karaf 2.2.0.
Currently they are fixed with Karaf 2.1.4.
You have to change that in the source code.
Those tests must be able to pass.

We should add to the release notes that Karaf 2.1.5 is required if
using Karaf 2.1.x. And that Karaf 2.2.0 is supported now.

However I also think we should also reserve a "slot" for doing a Camel
2.8 release in case issues and whatnot is needed by either or both the
SMX or AMQ team for their upcoming releases (SMX 4.4 and AMQ 5.5).




> Thanks,
> Hadrian
>
>
>
> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>
>> Hi
>>
>> On Thursday, March 10, 2011, Christian Schneider <cs...@talend.com> wrote:
>>> Hi all,
>>>
>>> I think the same way as Claus. We should try to not add any functional changes a few days before a release. That is the only way to make sure people have time to run their tests against the code base to be released.
>>> I was already hesitant to commit my patch for the servlet on friday.
>>>
>>> So I think we have two options for the features.xml issue. If it is really important for 2.7.0 we do a new release with it included in some days. If not we cut a release now with the reverted version, perhaps with Willems fixes.
>>
>> Yeah as christian says i think we got two options.
>> 1) re cut release without the features patch
>> 2) apply the patch and postpone the release for a week or longer, to
>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
>> the given jira ticket.
>>
>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>> needs a camel with karaf 2.2 and that features patch. Although we are
>> very likely to be able to cut a new camel 2.8 release beforehand.
>>
>> I am traveling for the next two weeks, so you guys can have fun
>> without me policing.
>> In light of this and the fact smx 4,4 need the patch, i am okay for
>> either option.
>>
>>
>>>
>>> So I think what we should do is define a code freeze some days before a release. During this time we should only commit bug fixes but not functional changes. In a less formal way we already do this.
>>> If we think this could slow down progress on the trunk then we could at this point create a branch for the release.
>>>
>>
>> Yeah we are usually good at having a slowdown up til the release is
>> cut. This time we had five or more days, which was really good. The
>> last major func. Change was that servlet improvements which imho is a
>> very good improvement. After this we fixed all the maven archetypes so
>> they are working again. Other than that its bug fixes and test fixes
>> leading up till the cut time.
>>
>>
>>
>>> Christian
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>> An: dev@camel.apache.org
>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>
>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>>
>>>>
>>>> I see now that Willem already reverted the patch, not clear why, I assume just based on your feelings. I would be very interested in seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>
>>>
>>> I really dont understand why you would think its "no brainer" to make such a big change "seconds" before you cut the release.
>>> You are usually very good and careful when you do the releases.
>>>
>>> The ticket its not a blocker for the 2.7 release. And it was already scheduled for Camel 2.8.
>>> And in terms of OSGi you have to be extra careful and test it more thoroughly than a simpler fix in a plain Camel component.
>>> The OSGi tests runs at the end of the CI process and thus they are more prone to not be run due test failures in pre-existing components.
>>> We all know it can be a little tricky to have CI 100% green.
>>> Hence its a good practice to also run those OSGi tests locally once in a while to ensure it works well.
>>>
>>>
>>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [PROPOSAL]

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi all,

FYI, I fixed KARAF-505 this morning.

Karaf 2.1.5 will support the resolver="(obr)" notation.

Regards
JB

On 03/11/2011 07:07 PM, Hadrian Zbarcea wrote:
> We knew this patch will go in, now or 2.8.0 which meant that the compatibility with karaf 2.1.x will be broken at some point. There is no real difference if we do it now or in 2.8.0 if 2.8.0 is released soon. If 2.8.0 is released much later, we give users something that is java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does already anyway), but we could negatively impact smx 4.4. Traditionally during the Camel lifetime we played very nice with other communities, especially those that rely directly on Camel.
>
> That said, my proposal is this:
> 1. We keep Jean Baptiste's patch.
> 2. JB opened and KARAF-505 and will commit a patch soon. As of the next Karaf 2.1.5 the compatibility will be restored.
> 3. We release Camel 2.7.0 either:
>   a. after a few days of testing (per Christian proposal, +1'd by Claus); the only impact of the patch is using the new obr features in Karaf 2.2.0 (which was tested, contrary to allegations), no other impacts; this leaves a few weeks of incompatibility from the Camel release to the Karaf 2.1.5 release
>   b. after the Karaf 2.1.5 release
>
> Personally I am ok with either 3a or 3b opting slightly towards 3a. If you have other proposals or a preference please speak up. I hope us to be in position to make a decision early next week.
>
> Thanks,
> Hadrian
>
>
>
> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>
>> Hi
>>
>> On Thursday, March 10, 2011, Christian Schneider<cs...@talend.com>  wrote:
>>> Hi all,
>>>
>>> I think the same way as Claus. We should try to not add any functional changes a few days before a release. That is the only way to make sure people have time to run their tests against the code base to be released.
>>> I was already hesitant to commit my patch for the servlet on friday.
>>>
>>> So I think we have two options for the features.xml issue. If it is really important for 2.7.0 we do a new release with it included in some days. If not we cut a release now with the reverted version, perhaps with Willems fixes.
>>
>> Yeah as christian says i think we got two options.
>> 1) re cut release without the features patch
>> 2) apply the patch and postpone the release for a week or longer, to
>> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
>> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
>> the given jira ticket.
>>
>> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
>> needs a camel with karaf 2.2 and that features patch. Although we are
>> very likely to be able to cut a new camel 2.8 release beforehand.
>>
>> I am traveling for the next two weeks, so you guys can have fun
>> without me policing.
>> In light of this and the fact smx 4,4 need the patch, i am okay for
>> either option.
>>
>>
>>>
>>> So I think what we should do is define a code freeze some days before a release. During this time we should only commit bug fixes but not functional changes. In a less formal way we already do this.
>>> If we think this could slow down progress on the trunk then we could at this point create a branch for the release.
>>>
>>
>> Yeah we are usually good at having a slowdown up til the release is
>> cut. This time we had five or more days, which was really good. The
>> last major func. Change was that servlet improvements which imho is a
>> very good improvement. After this we fixed all the maven archetypes so
>> they are working again. Other than that its bug fixes and test fixes
>> leading up till the cut time.
>>
>>
>>
>>> Christian
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>> Gesendet: Donnerstag, 10. März 2011 11:44
>>> An: dev@camel.apache.org
>>> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>>>
>>> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian Zbarcea<hz...@gmail.com>  wrote:
>>>
>>>>
>>>> I see now that Willem already reverted the patch, not clear why, I assume just based on your feelings. I would be very interested in seeing Guillaume's opinion, as a Karaf/OSGi expert.
>>>>
>>>
>>> I really dont understand why you would think its "no brainer" to make such a big change "seconds" before you cut the release.
>>> You are usually very good and careful when you do the releases.
>>>
>>> The ticket its not a blocker for the 2.7 release. And it was already scheduled for Camel 2.8.
>>> And in terms of OSGi you have to be extra careful and test it more thoroughly than a simpler fix in a plain Camel component.
>>> The OSGi tests runs at the end of the CI process and thus they are more prone to not be run due test failures in pre-existing components.
>>> We all know it can be a little tricky to have CI 100% green.
>>> Hence its a good practice to also run those OSGi tests locally once in a while to ensure it works well.
>>>
>>>
>>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>