When the Camel OSGi folks have a second, Claus asked that I get your input.
Thanks in advance. Best Regards, Scott ES On Mon, Dec 3, 2012 at 4:03 PM, Scott England-Sullivan <sully6...@gmail.com>wrote: > Exactly. > > For that matter, any API that has Spring Namespace support, such as CXF, > would work seamlessly with a Camel Gemini Blueprint component. > > > On Mon, Dec 3, 2012 at 3:43 PM, Daniel Kulp <dk...@apache.org> wrote: > >> >> Also keep in mind that even just porting the camel-blueprint stuff >> wouldn't provide 100% of the functionality. For example, the CXF >> blueprint stuff for camel-cxf relies heavily on the blueprint support in >> CXF which is also highly tied to Aries. >> >> Dan >> >> >> On Dec 3, 2012, at 1:00 PM, Scott England-Sullivan <sully6...@gmail.com> >> wrote: >> >> > It hasn't been forgotten, just on-hold while I have been out on >> > assignments. ;-) >> > >> > I will be back and able to continue this when I return next week. >> > >> > To stimulate discussion while I am out though, I still believe we will >> need >> > a dedicated Camel Gemini Blueprint component as the current Camel >> Blueprint >> > is tightly coupled to Aries Blueprint and there isn't a direct >> translation >> > to the same capabilities in Gemini Blueprint. >> > >> > Also, Gemini Blueprint is tightly coupled to Spring and folks that use >> it >> > also use Spring stuff (like the Spring Context namespace which Gemini >> > supports). It makes the most sense to develop a component for the two >> > blueprint implementations independently. Camel already has mature >> Spring >> > support so we should take advantage of it. >> > >> > I know it would be "cleaner" if the current Camel Blueprint component >> could >> > support either implementation but I believe the changes would be very >> > extensive and make it difficult to, if not eliminate, the ability to >> > support the extensions that both implementations provide that our users >> > depend on. >> > >> > Just my two cents... >> > >> > >> > >> > On Sun, Dec 2, 2012 at 4:12 AM, Benjamin Graf <benjamin.g...@gmx.net> >> wrote: >> > >> >> 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 >> >>>> >> >>> >> >>> >> >> >> >> >> >> >> > >> > >> > -- >> > -- >> > 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 >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> > > > -- > -- > 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 > > -- -- 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
