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/
