camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott England-Sullivan <sully6...@gmail.com>
Subject Re: [DISCUSION] Adding Support For Gemini Blueprint
Date Tue, 06 Nov 2012 14:31:23 GMT
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.graf@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.graf@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message