Yes, there is no easy way to support both version of Spring at the same
time just by using the maven profile.
Even we use the maven profile, we could put the
CamelSpringTestContextLoader for spring 3.1 to other directory to let
compiler to pick up. We can only support one version of spring in the
deploy time.
As we barely use the @CamelSpringJUnit4ClassRunner. Maybe we could
consider to build the kit with Spring 3.1 and run the unit test with
spring 3.0.x
Just my 2 cents.
On 3/12/12 5:45 AM, Christian Müller wrote:
Could you please have a look at [1]. I think it's not possible to
support both versions, but I would be happy if I'm wrong...
[1] https://issues.apache.org/jira/browse/CAMEL-4778
Best,
Christian
On Sun, Mar 11, 2012 at 2:50 PM, Willem Jiang <[email protected]
<mailto:[email protected]>> wrote:
+1 to run test with Spring 3.1 profile.
As Spring always has a good backward compatibility, I don't think we
will hit the test issue when we upgrade to Spring 3.1.
On 3/11/12 3:12 AM, Christian Müller wrote:
I will add a spring-3.1 profile in my local workspace and see
how it works
(we could have a Spring 3.0.x and a Spring 3.1.x build). If this
works I
will move on and see how we do it for Karaf...
Best,
Christian
On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller<
[email protected]
<mailto:[email protected]>> wrote:
Maybe Stefan don't use the Camel provided features and
install all the
needed bundles by its own or build its own feature file
which use Spring
3.1.x. That's possible but not recommended, because Camel
2.9.1 is "only"
tested with Spring 3.0.x. This means it could work, but you
cannot be sure.
It's also possible that may camel-jpa works with Spring
3.1.x but another
Camel component e.g. camel-jms/camel-activemq will fail with
Spring 3.1.x.
In the past we already did support two different versions of
Spring (2.5.x
and 3.0.x). I'm not sure were we was happy with this
solution (two
different feature files in Camel)...
Loud thinking:
At the moment I'm not sure if it's really the best idea that
Camel reuse
the Karaf provided Spring feature (may be this is also the
case for other
features). The reason is the following:
Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and
you don't want
to upgrade your container infrastructure multiple times per
year (this is
the case for my company). When you upgrade your Camel based
application to
a Camel version which use Spring 3.1.x, you have to:
- upgrade your container infrastructure also (Karaf)
- or change the Camel provided feature file and change all
the places
where Camel requires the Spring feature (from Karaf) and
replace it with
the Spring 3.1.x bundles.
Be leveraging the Karaf Spring features it's easier to have
all the
dependencies in sync, but it adds an (unnecessary) constraint.
And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix
this constraint...
I'm interested in your all opinions.
Best,
Christian
On Sat, Mar 10, 2012 at 5:01 PM,
wanggang1<[email protected] <mailto:[email protected]>>
wrote:
Hi Stefan,
When I used Camel 2.9.1, I saw Maven pulled down Spring
3.0.7-RELEASE as
dependencies. When you added Spring 3.1 explicitly, did
it then cause any
conflict?
Thanks
--
View this message in context:
http://camel.465427.n5.nabble.__com/Camel-and-Spring-3-1-__tp5550625p5553179.html
<http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html>
Sent from the Camel - Users mailing list archive at
Nabble.com.
--
Willem
------------------------------__----
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.__com
<http://willemjiang.blogspot.com> (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
