Is there a newer or extension bundle than: pax-cdi-api-1.0.0.RC1.jar I don't see these annotations in there an Eclipse can't find them. org.ops4j.pax.cdi.api.Component org.ops4j.pax.cdi.api.Immediate org.ops4j.pax.cdi.api.Service
On Tue, Sep 6, 2016 at 11:09 AM, Guillaume Nodet <[email protected]> wrote: > The new annotations are > org.ops4j.pax.cdi.api.Component > org.ops4j.pax.cdi.api.Immediate > org.ops4j.pax.cdi.api.Service > ... > > Those annotations are different from the SCR or DS annotations, so you > clearly do not need the felix scr annotations bundle. > > Guillaume > > 2016-09-06 17:51 GMT+02:00 Brad Johnson <[email protected]>: > >> @gnodet >> >> I have been using the new CDI along with Camel 2.17.3 and it sounds as if >> I don't need the SCR at all then? So I'd be able to remove the felix scr >> annotations dependency? The last element in the list which I've italicized. >> >> <dependency> >> <groupId>javax.enterprise</groupId> >> <artifactId>cdi-api</artifactId> >> </dependency> >> <dependency> >> <groupId>org.ops4j.pax.cdi</groupId> >> <artifactId>pax-cdi-api</artifactId> >> <version>1.0.0.RC1</version> >> </dependency> >> <dependency> >> <groupId>org.apache.camel</groupId> >> <artifactId>camel-cdi</artifactId> >> </dependency> >> *<dependency>* >> * <groupId>org.apache.felix</groupId>* >> * <artifactId>org.apache.felix.scr.annotations</artifactId>* >> * </dependency>* >> >> >> On Tue, Sep 6, 2016 at 10:47 AM, Brad Johnson < >> [email protected]> wrote: >> >>> @gnodet >>> >>> Thanks for the info regarding the @OsgiServe/@OsgiServiceProvider. >>> Perhaps that's where I go the idea that one needed to specify start up >>> order on bundles. In some recent test projects I have been using the Felix >>> SCR but most of the testing has been using the CamelCDI runner as it is >>> very fast. That obviously creates some problems with having to double >>> annotate some items for Inject vs Reference and so on and the fact that CDI >>> isn't going to respect bundle boundaries inside the test. But that isn't a >>> huge problem because in the context of testing it isn't like I have 300 >>> bundles running. It's just a few application bundles and their >>> dependencies. >>> >>> It does mean I'll have to get ready to deal with some errors when moving >>> from the IDE environment over to the Karaf/felix environment but for >>> development/testing speed it definitely seems worth it. >>> >>> I'm so used to using CamelBlueprintTestSupport and blueprint.xml that >>> all of this still feels a bit left handed -- "If I were doing this in >>> blueprint, this what I'd do...." >>> >>> On Mon, Sep 5, 2016 at 6:38 AM, Guillaume Nodet <[email protected]> >>> wrote: >>> >>>> I don't really recommend using the @OsgiService / @OsgiServiceProvider >>>> of Pax-CDI. >>>> The main reason is that if the bundles are not started in the correct >>>> order, the bean validation will simply fail and your CDI app won't be >>>> created at all. >>>> I'd really recommend to look at the new annotations of Pax-CDI which >>>> haven't been released yet (in 1.0.0-SNAPSHOT). They are very similar to >>>> the DS semantics (and they actually use part of Felix SCR implementation as >>>> the core engine). The lifecycle of the CDI beans is similar to those of >>>> DS, so the dependency mechanism is really straightforward from a user point >>>> of view. >>>> >>>> Cheers, >>>> Guillaume >>>> >>>> 2016-09-02 19:46 GMT+02:00 Brad Johnson <[email protected]>: >>>> >>>>> Matt, >>>>> >>>>> For the past few weeks I've been working with the Camel 2.17 CDI and >>>>> it's marvelous. I've been using blueprint for a few years now and I won't >>>>> be going back to twiddling XML unless I have to (I'm not sure how to set >>>>> up >>>>> CXF server without it right now). But the CDI test runner is fast and a >>>>> snap to use. The annotation automated wire up and RouteBuilder automatic >>>>> running is just like you'd think ought to be. >>>>> >>>>> The pax-cdi implementation actually creates blueprint proxies for >>>>> annotations like @OSGiServiceProvider and will inject it where you specify >>>>> the service consumer. The only caveat to the CDI test runner is that it is >>>>> not OSGi based but uses Weld. So you have to be careful about what you >>>>> test but I can live with that. Truly stunning when one sees a technology >>>>> that works almost like magic - like you'd dream it should work. >>>>> >>>>> On Fri, Sep 2, 2016 at 12:04 PM, Matt Sicker <[email protected]> wrote: >>>>> >>>>>> On 2 September 2016 at 11:30, Timothy Ward <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> As things stand currently blueprint is most widely used for working >>>>>>> with Camel. From what I can tell configuring Camel is horrible, and my >>>>>>> understanding is that the main advantage of blueprint is that there is a >>>>>>> huge amount of ready-built Camel integration available. If Camel had a >>>>>>> nicer, container agnostic configuration mechanism then I would see >>>>>>> little >>>>>>> reason to choose blueprint over DS. >>>>>>> >>>>>> >>>>>> This right here is exactly how I feel. If there was a well supported >>>>>> way of simply using DS instead of Blueprint with Camel, then I'd drop >>>>>> Blueprint in a single sprint and never look back. >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> ------------------------ >>>> Red Hat, Open Source Integration >>>> >>>> Email: [email protected] >>>> Web: http://fusesource.com >>>> Blog: http://gnodet.blogspot.com/ >>>> >>>> >>> >> > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > >
