To be more clear and let room for discussion (and still be able to work), i'll do the following: * extract the xml / jabx logic in a separate maven module named components/camel-core-xml * extract the osgi bits in a new module components/camel-core-osgi To minimize changes, camel-spring will embed the classes from camel-core-xml and camel-osgi will embed those from camel-core-osgi, while camel-blueprint will embed both.
When we have that, it will be easier to discuss the need to maintain those modules or refactor those. My proposal came from the fact that it's a bit confusing to have camel-osgi, camel-spring and camel-spring-osgi. I think camel-spring should be sufficient... On Fri, May 7, 2010 at 09:06, 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 > * 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 > > Thoughts ? > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
