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
