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
