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>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 > >
signature.asc
Description: OpenPGP digital signature
