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 Mon, 03 Dec 2012 18:00:25 GMT
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

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