Well, any support for Gemini blueprint would indeed need to be done separately from the current support of Aries Blueprint. The main reason is that the part of blueprint used (i.e. custom namespaces) isn't specified in the blueprint spec and need to be written differently in both cases.
On Tue, Jan 8, 2013 at 5:07 PM, Scott England-Sullivan <sully6...@gmail.com>wrote: > Hi Charles, > > Thanks for responding. > > This is where the confusion starts. After a review of Gemini Blueprint, I > wouldn't look at it as something associated with Camel Blueprint or Karaf > at all. You have to look at it from a Camel Spring and or Spring DM > perspective as it is meant to be a "drop in" replacement for Spring DM. > With that, Gemini Blueprint doesn't offer full backwards compatibility for > Spring DM so I wouldn't recommend just swapping APIs in Camel Spring as it > would need more testing in Karaf. > > Regardless, for containers that do support Gemini Blueprint, this should > work as a completely separate project (Camel Gemini Blueprint) that would > need to internalize the necessary Spring bits from the Camel Spring > project. > > Thoughts? > > Best Regards, > Scott ES > > PS: My review of Gemini Blueprint is about two months old so I apologize if > some of this is out of date. > > On Tue, Jan 8, 2013 at 9:25 AM, Charles Moulliard <ch0...@gmail.com> > wrote: > > > Hi, > > > > Does that make sense to support Gemini Blueprint in Camel 2.11 while > until > > now Camel Blueprint is not to handle Tx (and should be improved) and when > > also Karaf is not able to support Gemini Blueprint ... ? > > I would prefer that we concentrate our efforts to finalize Camel > Blueprint > > before starting a discussion or implementation of Gemini Blueprint. > > > > Just 2€ ;-) > > > > Regards, > > > > > > On Tue, Jan 8, 2013 at 3:52 PM, Scott England-Sullivan > > <sully6...@gmail.com>wrote: > > > > > Hi Claus, > > > > > > I would still like to resolve the Gemini Blueprint support issue > > CAMEL-5743 > > > <https://issues.apache.org/jira/browse/CAMEL-5743>. If the > > OSGi/Blueprint > > > folks could chime in I would appreciate it. > > > > > > There is a thread about this already so comments there would be > > > appreciated. > > > > > > Best Regards, > > > Scott ES > > > > > > On Mon, Jan 7, 2013 at 7:31 AM, Claus Ibsen <claus.ib...@gmail.com> > > wrote: > > > > > > > Hi > > > > > > > > I think we should start closing down on the upcoming Camel 2.11 > > release. > > > > > > > > There is a few important tickets which IMHO needs to be resolved > > > > before we are in shape. > > > > > > > > 1) > > > > New set of OSGi bundles from the SMX team. > > > > There is some new Camel components and JAR upgrades that requires a > > > > new set of OSGi bundles. > > > > > > > > 2) > > > > Upgrade to Scala 2.10 > > > > The 3rd party component which we depend on in camel-web have been > > > > upgraded to Scala 2.10 (eg scalate). > > > > So we ought to be in a position to upgrade camel-scala to Scala 2.10. > > > > What is missing is an OSGi bundle for Scala 2.10. (eg see #1) > > > > > > > > 3) > > > > Apache Karaf 2.3.1 release > > > > > > > > We need Karaf 2.3.x to support Spring 3.1 out of the box. Currently > it > > > > has an issue causing both Spring 3.0 and 3.1 > > > > to be installed if you install Camel in Karaf. > > > > > > > > There is a post on Karaf @dev about this, and the Karaf team seems > > > > willingly to fix this. And hopefully cut a new release > > > > with this fix. > > > > > > > > 4) > > > > We should revisit the open ticket, and get stuff either fixed or > > > > postponed to either Camel 2.12 or 2.11.1. > > > > > > > > 5) > > > > Look at CI and fix any test issues and other build issues. > > > > I think there is a camel-jclouds failure. > > > > > > > > 6) > > > > If there is stuff you want to be included in Camel 2.11, then let us > > > know. > > > > > > > > > > > > > > > > -- > > > > Claus Ibsen > > > > ----------------- > > > > Red Hat, Inc. > > > > FuseSource is now part of Red Hat > > > > Email: cib...@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 > > > > > > > > > > > -- > > Charles Moulliard > > Apache Committer / Sr. Enterprise Architect (RedHat) > > Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.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 > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
