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
