L.S., Guillaume's suggestion is to create a separate JAR with the OSGi helper bits and embed that in both camel-blueprint and camel-spring. I don't think there's a real problem with a compile-time dependency, as long as we mark the Maven dependency optional in the pom.xml -- we just have to make sure that we don't use the OSGi specific classes when running in a non-OSGi environment and then we should be fine there, shouldn't we?
I suppose the goal is to look for Camel bundles and register components, converters, languages, ... in the OSGi Service Registry so we can respond to changes in the environment for our Blueprint and Spring DM deployed routes. For example: for camel-blueprint, we could set-up a component/converter/... locator class in an OSGI-INF/blueprint/camel.xml file which would only get started in an OSGi- and Blueprint-aware container to avoid the tight link. I'm not entirely sure about META-INF/spring/*.xml for camel-spring, but I don't think that will get automatically picked up in a non-spring-dm environment either. One other question: shouldn't we consider to build support for deploying Camel in a pure OSGi environment as well (like an embedded environment or inside Eclipse) without requiring the use of either Spring DM or Blueprint (although the latter is probably lightweight enough to be installed in almost any environment) -- e.g. have a ServiceTracker to track RouteBuilder instances in the OSGi Service Registry and have a means of auto-starting them (e.g. by adding some property when registering the service)? Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 7 May 2010 09:19, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Fri, May 7, 2010 at 9:06 AM, Guillaume Nodet <gno...@gmail.com> wrote: >> I'm working on improving and refactoring the OSGi bits and I'd like to >> propose the following: >> * make camel-osgi a plain jar just used to share common code between >> camel-blueprint and camel-spring >> this jar would contain osgi specific classes and also common code for >> jaxb parsing / factory logic > > >> both camel-spring and camel-blueprint would embed the classes defined >> here as to simplify deployment > > How would that be possible for camel-spring to NOT require any osgi jars at > all, > for people who simply want to use Camel in non osgi environments? > > > The problematic part as I see, is the "logic" which is required in > camel-spring to prepare the routes before they are ready to be used at > runtime. > This logic is a bit extensive and would require to be duplicated for > blueprint as well. > > This has annoyed me that camel-spring required this work, where as > camel-core would not (eg there is a potential difference between Java > DSL and Spring XML routes). Hence I have though of refactoring this > logic into camel-core so both Java DSL and Spring XML leverages it. > I have though of attempting that for Camel 3.0. But in light of this > we could consider moving this forward. > > Then if implemented then camel-blueprint and camel-spring can be > independent of each other, as they are today. > > >> * merge camel-spring-osgi back into camel-spring >> this would be easier for end users i think as they would just have to >> deploy camel-spring and that's all >> whether they are in an osgi environment or not would be transparent >> > > Still I don't see this possible. Its important that OSGi does not > become invasive in any way for people not using it at all. > And that means no OSGi jars required at runtime. > > > > >> Thoughts ? >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus >
