Hey Willem, On Wed, Mar 16, 2011 at 4:59 AM, Willem Jiang <willem.ji...@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é<j...@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<cschnei...@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.ib...@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<hzbar...@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: cib...@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 >
