Re: [DISCUSION] Adding Support For Gemini Blueprint

[Benjamin Graf]

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/:


{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>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