I didn't see this thread until now, but just wanted to add that I use blueprint with Camel all the time very successfully. There were a few hiccups that were resolved around injecting configurations into the tests for a specific PID, but in the testing stuff was put together nicely as well.
I'd be curious what specific problems you have with it since I was able to figure it out pretty easily from the Camel documentation. I would however like to see some of these hurdles in general get addressed. I'd like to see open source projects in general modularize themselves. When I need to use one that just half-@ssed some osgi support or no osgi support but split packages in their jars, it's quite frustrating. I love writing code using osgi. The power you have is tough to wield at first, but you can do some awesome stuff when you figure it out (and workaround some of the current hurdles still be hashed out). Ryan Ryan On Wed, Nov 21, 2018, 1:34 PM Raymond Auge <[email protected] wrote: > > > On Wed, Nov 21, 2018 at 11:23 AM Ranx <[email protected]> wrote: > >> Raymond, >> >> Thanks for the information. I was probably unaware of the RI because it >> isn't listed on the Aries website > > > Good point! So I did some updates to the main page [1]. I will try to make > further updates to other pages as time permits. > > [1] http://aries.apache.org/ > > >> and the only annotations I was aware of >> from there were the Blueprint annotations. Also, PAX CDI has been >> installed >> in Fuse for some time now although in the 6.x version (Karaf 2.x) it was >> only the RC so i refrained from using it for production code. Fuse 7 is >> currently Karaf 4.2.x and has the 1.2 version of PAX CDI installed as a >> default. >> >> I think I saw a presentation you gave at Eclipsecon Europe (on Youtube) on >> the work you were doing with CDI and OSGi/J2EE. There seemed to be a lot >> of >> work going on there for interoperability with J2EE and not just as OSGi. > > > So there's nothing really specific to Java EE per say other than to ensure > that OSGi CDI Integration could naturally accommodate other CDI Portable > Extensions in a friendly, portable way. As such, integration of Java EE > specs could be accomplished without any hacks. This model could be used > just as easily to make your own features available to your CDI bundles. > > >> For >> me the J2EE part isn't as relevant but if the OSGi service dynamism and >> injection and wire up work correctly that works for me. >> > > Perfect, so there's nothing for you to worry about because this is the > base model. > > >> >> Now to get Red Hat to embrace it and it'll be golden. >> > > Sure, let's see what we can do! ;) > > - Ray > > >> >> >> >> -- >> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > (@OSGiAlliance) >
