We may add a profile in the camel-test-spring module and consider this
feature is only support in Spring 3.1.
We can let the profile pick up the dependency of spring-test and the
CamelSpringTestContextLoader at that time.
If the people want to have a try with the spring test , he need to
rebuild the camel-test-spring with profile Spring 3.1.
Or we just postpone this feature to Camel 3.0.
Any thought?
On Wed Mar 14 06:18:13 2012, Christian Müller wrote:
David,
could you please have a loot at this whether you see a way to support both
versions (Spring 3.0 and 3.0). At present we only discovered an issue with
the CamelSpringTestContextLoader which is a new class added in Camel
2.10.0. If it's not possible, I'm +1 to postpone the changes we did for [1]
to Camel 2.11.0/3.0.0.
[1] https://issues.apache.org/jira/browse/CAMEL-4987
My 0.02$,
Christian
On Tue, Mar 13, 2012 at 6:59 AM, Claus Ibsen<[email protected]> wrote:
On Tue, Mar 13, 2012 at 2:57 AM, Willem Jiang<[email protected]>
wrote:
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.
If its the CamelSpringTestContextLoader then its a new class
introduced by David with his work on camel-test-spring.
It has not been released as part of any previous Camel releases.
So we can change it anyway we like, or *remove* it etc.
IMHO its better to support both Spring 3.0 and 3.1 out of the box with
no tricks.
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
There are people who build from source, and they may build with Spring
3.0.x.
So its not always so easy.
I suggest Camel 2.10 to support both Spring 3.0 and 3.1 (the latter if
possible). We will have a lot of end users
who are using either version of Spring.
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
--
Claus Ibsen
-----------------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
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
Weibo: willemjiang
