camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: [DISCUSION] Adding Support For Gemini Blueprint
Date Mon, 03 Dec 2012 20:43:55 GMT

Also keep in mind that even just porting the camel-blueprint stuff wouldn't provide 100% of
the functionality.   For example, the CXF blueprint stuff for camel-cxf relies heavily on
the blueprint support in CXF which is also highly tied to Aries.

Dan


On Dec 3, 2012, at 1:00 PM, Scott England-Sullivan <sully6768@gmail.com> wrote:

> It hasn't been forgotten, just on-hold while I have been out on
> assignments.  ;-)
> 
> I will be back and able to continue this when I return next week.
> 
> To stimulate discussion while I am out though, I still believe we will need
> a dedicated Camel Gemini Blueprint component as the current Camel Blueprint
> is tightly coupled to Aries Blueprint and there isn't a direct translation
> to the same capabilities in Gemini Blueprint.
> 
> Also, Gemini Blueprint is tightly coupled to Spring and folks that use it
> also use Spring stuff (like the Spring Context namespace which Gemini
> supports).  It makes the most sense to develop a component for the two
> blueprint implementations independently.  Camel already has mature Spring
> support so we should take advantage of it.
> 
> I know it would be "cleaner" if the current Camel Blueprint component could
> support either implementation but I believe the changes would be very
> extensive and make it difficult to, if not eliminate, the ability to
> support the extensions that both implementations provide that our users
> depend on.
> 
> Just my two cents...
> 
> 
> 
> On Sun, Dec 2, 2012 at 4:12 AM, Benjamin Graf <benjamin.graf@gmx.net> wrote:
> 
>> Hi,
>> 
>> any new suggestions to this discussion? It seems the discussion has been
>> forgotten. :-)
>> 
>> Best,
>> Benjamin
>> 
>> On 06.11.2012 17:25, Scott England-Sullivan wrote:
>>> That makes sense.  I will table it until next week.
>>> 
>>> Thanks to you both Willem and Claus.
>>> 
>>> On Tue, Nov 6, 2012 at 10:13 AM, Claus Ibsen <claus.ibsen@gmail.com>
>> wrote:
>>> 
>>>> 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
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> -- 
> -- 
> 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

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message