camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: [PROPOSAL]
Date Wed, 16 Mar 2011 03:59:15 GMT
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<cschneider@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<hzbarcea@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

Mime
View raw message