Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.215.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANZYW6bWsG4a=GB7DZBn7sHgVFbv6Cq6SH=XyNyJFQAsBzb5jw@mail.gmail.com>
References: 
 <CANZYW6aYYCozRkefWDJQw7rPC36-jSp9YHG4KZHzK2U4YeEUhg@mail.gmail.com>
 <50980713.8090202@gmx.net>
 <CANZYW6bdtHzMxd0vUbiOKB0XvH-opgmp-mv=RsWE8nrYzz6FdQ@mail.gmail.com>
 <5098294D.8070501@gmx.net>
 <CANZYW6bWsG4a=GB7DZBn7sHgVFbv6Cq6SH=XyNyJFQAsBzb5jw@mail.gmail.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Tue, 6 Nov 2012 17:13:46 +0100
Message-ID: 
 <CAGB5yNkqQhjDyMfVerTN028CGNMMyvvbjp=bY9d8S+uyTkJDBw@mail.gmail.com>
Subject: Re: [DISCUSION] Adding Support For Gemini Blueprint
To: dev@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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
<sully6768@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.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


-- 
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen