Hi Willem, do not forget that Gemini Blueprint has strong dependencies to Spring Framework and therefor also to camel-spring. Camel-spring depends on spring-dm jars which are incompatible with gemini-blueprint jars!
Looking forward to OSGi experts opinions. :-) Benjmain -------- Original-Nachricht -------- > Datum: Tue, 6 Nov 2012 23:01:42 +0800 > Von: Willem jiang <willem.ji...@gmail.com> > An: dev@camel.apache.org > Betreff: Re: [DISCUSION] Adding Support For Gemini Blueprint > Hi Scott, > > I think we don't need the camel-spring-dm component, as the we support the > sprint-dm in camel-spring module for very long time. > If I remember right, we hit some OSGi related issues when install > camel-spring and camel-osgi modules with different order. > > If we just use Gemini as blueprint implementation is could make the things > easy, we don't need to care about the backwards compatible things any > more. > It could be great for us to provides the camel-blueprint components which > can leverage different blueprint implementations. > > -- > Willem Jiang > > Red Hat, Inc. > FuseSource is now part of Red Hat > Web: http://www.fusesource.com | http://www.redhat.com > Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) > (English) > http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese) > Twitter: willemjiang > Weibo: willemjiang > > > > > > On Tuesday, November 6, 2012 at 10:31 PM, Scott England-Sullivan wrote: > > > If nobody has an issue with it I am proceeding with option 3. > > > > Any concerns? > > > > On Mon, Nov 5, 2012 at 3:02 PM, Benjamin Graf <benjamin.g...@gmx.net > (mailto:benjamin.g...@gmx.net)> wrote: > > > > > Hi Scott, > > > > > > sounds reasonable. :-) > > > > > > Benjamin > > > > > > > > > On 05.11.2012 21:46, Scott England-Sullivan wrote: > > > > > > > Hi Benjamin, > > > > > > > > Its not that I found anything with Camel. Its the documentation from > the > > > > Gemini Blueprint project that concerns me. Reading the following: > > > > > > > > From the Gemini Blueprint Migration Document > > > > > http://www.eclipse.org/gemini/**blueprint/documentation/**migration/<http://www.eclipse.org/gemini/blueprint/documentation/migration/> > > > > : > > > > > > > > > > > > {snip} > > > > > > > > ** Removed deprecated modules ** > > > > > > > > As of Gemini Blueprint M1, not all modules or projects inside Spring > DM > > > > have been moved. At the moment only the io, core, extender and test > > > > modules > > > > have transitioned are provided in M1. With the up-coming release of > OSGi > > > > RFC-66, the web support is being discontinued. Existing users are > > > > encouraged to look at Eclipse Gemini Web project. The plans for the > Maven > > > > archetype and annotation extension are undefined for the moment and > these > > > > modules are NOT included in Gemini Blueprint project. > > > > > > > > {snip} > > > > > > > > > > > > While there may be minimal or small issues for Camel itself, Camel > Users > > > > may have extended or used features based on Spring DM. Given that, I > > > > don't > > > > feel comfortable stating anything less than it can/will break > backwards > > > > compatibility. > > > > > > > > Make sense? > > > > > > > > On Mon, Nov 5, 2012 at 12:36 PM, Benjamin Graf > <benjamin.g...@gmx.net (mailto:benjamin.g...@gmx.net) > > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I would recommend Option 3a with an additional rename of > camel-blueprint > > > > > component to camel-aries-blueprint just to be clean and avoid any > further > > > > > friction. > > > > > > > > > > Btw. which breaking backwards compatibilities did you find with > Spring DM > > > > > and > > > > > Gemini Blueprint in Option 1 Cons? I didn't find any while > evaluating, > > > > > but > > > > > you're right that this can change in the future. > > > > > > > > > > Best, > > > > > Benjamin > > > > > > > > > > On 05.11.2012 17:58, Scott England-Sullivan wrote: > > > > > > > > > > > Hello All, > > > > > > > > > > > > We have had a request to add support for Gemini Blueprint in > Camel. I > > > > > have > > > > > > > > > > > logged ticket CAMEL-5743 > > > > > > > <https://issues.apache.org/**jira/browse/CAMEL-5743<https://issues.apache.org/jira/browse/CAMEL-5743>>to > > > > > > track it. Gemini > > > > > > Blueprint is not fully backwards compatible with > > > > > > Spring DM though requiring some decisions on how to support it > moving > > > > > > forward. I have assembled the options below and would like some > > > > > > feedback > > > > > > before moving forward. They are: > > > > > > > > > > > > > > > > > > Option 1: Upgrade camel-spring to Gemini Blueprint > > > > > > > > > > > > ------------------------------**------------------------------** > > > > > ----------------- > > > > > > > > > > > Simple update to the current camel-spring component to use > Gemini > > > > > Blueprint > > > > > > > > > > > 1.0.x > > > > > > > > > > > > Pros: > > > > > > * Simplest > > > > > > * Requires limited changes to current ITests > > > > > > > > > > > > Cons: > > > > > > * Breaks backwards compatibility with Spring DM as some of the > current > > > > > > Spring DM features are not or no longer will be supported by > Gemini > > > > > > Blueprint > > > > > > * Breaks backwards compatibility with camel-spring > > > > > > > > > > > > > > > > > > Option 2: Create a new camel-gemini-blueprint component > > > > > > > > > > > > ------------------------------**------------------------------** > > > > > ----------------- > > > > > > > > > > > This option keeps the camel-spring component as-is and create a > new > > > > > > camel-gemini-blueprint component. Since the current camel-spring > > > > > > > > > > > > > > > component > > > > > > > > > > > has Spring DM support embedded would not be possible to have > both > > > > > > camel-spring and camel-gemini-blueprint deployed to the same > container. > > > > > > > > > > > > > > > We > > > > > > > > > > > would need to copy the necessary bits of the camel-spring > component into > > > > > > the new camel-gemini-blueprint component using Maven to make the > new > > > > > > component completely independent of camel-spring. > > > > > > > > > > > > Pros: > > > > > > * Keeps camel-spring backwards compatible > > > > > > > > > > > > Cons: > > > > > > * Kludgy but works > > > > > > * Possible maintenance issues > > > > > > * Requires a new and separate ITest project to test Gemini > Blueprint > > > > > > > > > > > > > > > based > > > > > > > > > > > Camel code > > > > > > > > > > > > > > > > > > Option 3: Create new camel-spring-dm and camel-gemini-blueprint > > > > > components > > > > > ------------------------------**------------------------------** > > > > > ----------------- > > > > > > > > > > > This option would move the current Spring DM/OSGi support to a > new > > > > > > camel-spring-dm component. Both the new camel-spring-dm and > > > > > > camel-gemini-blueprint component would then have a dependency on > > > > > > camel-spring without the need to copy resources into either > component. > > > > > > > > > > > > Pros: > > > > > > * Clean separation of the code allows each component to be > supported and > > > > > > > > > > > > > > > to > > > > > > > > > > > evolve independently > > > > > > > > > > > > Cons: > > > > > > * Requires new feature definitions > > > > > > * Requires a new and separate ITest project to test Gemini > Blueprint > > > > > > > > > > > > > > > based > > > > > > > > > > > Camel code > > > > > > > > > > > > > > > > > > Option 4: ??? > > > > > > > > > > > > ------------------------------**------------------------------** > > > > > ----------------- > > > > > > > > > > > > > > > > > I personally believe Option 3 is the correct path moving forward > but > > > > > > what > > > > > > are your thoughts? > > > > > > > > > > > > > > > > > > Thanks in advance, > > > > > > Scott ES > > > > > > > > > > > > > > > > > > > > > > -- > > -- > > Scott England-Sullivan > > Apache Camel Committer > > Principal Consultant / Sr. Architect | Red Hat, Inc. > > FuseSource is now part of Red Hat > > Web: fusesource.com <http://www.fusesource.com> | > > redhat.com<http://www.redhat.com> > > Blog: sully6768.blogspot.com (http://sully6768.blogspot.com) > > Twitter: sully6768 > > >
