That makes sense. I will table it until next week. Thanks to you both Willem and Claus.
On Tue, Nov 6, 2012 at 10:13 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > A number of the OSGi guys are at ApacheCon EU and thus not online as much. > I would like to give some time for them to give feedback, before any > decision / commits is done on the codebase. > > > On Tue, Nov 6, 2012 at 3:31 PM, Scott England-Sullivan > <sully6...@gmail.com> 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> > 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 > >>> >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 > > Twitter: sully6768 > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > -- -- 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 Twitter: sully6768
