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 21:03:14 GMT
Exactly.

For that matter, any API that has Spring Namespace support, such as CXF,
would work seamlessly with a Camel Gemini Blueprint component.


On Mon, Dec 3, 2012 at 3:43 PM, Daniel Kulp <dkulp@apache.org> wrote:

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


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