Hi, any new suggestions to this discussion? It seems the discussion has been forgotten. :-)
Best, Benjamin On 06.11.2012 17:25, Scott England-Sullivan wrote: > 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 >> > >
signature.asc
Description: OpenPGP digital signature
