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/
