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
