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
