On Fri, May 7, 2010 at 10:34 AM, Gert Vanthienen <gert.vanthie...@gmail.com> wrote: > 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? >
Yeah that is possible if its a separate JAR. Which we in fact already have with camel-osgi. > 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 >> > -- 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
