You need to use the 1.0.0-SNAPSHOT version available from the following maven repository: https://oss.sonatype.org/content/*reposito*ries/ops4j-snapshots I've just uploaded a new version to make sure it's up to date.
2016-09-06 20:50 GMT+02:00 Brad Johnson <[email protected]>: > 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/ >> >> > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
