http://www.mail-archive.com/users%40felix.apache.org/msg16883.html sorry I linked to my email because I make hasty decisions. This link talks about the additions better.
On Wed, Apr 27, 2016 at 12:57 PM, David Daniel <[email protected]> wrote: > For what it is worth I would love to see the karaf shell start to see what > they could give back to the gogo shell. For awhile it seemed like no work > was going into improving the gogo shell but recently Guillaume has been > putting in some good improvements > https://mail.google.com/mail/u/0/#search/jline/1539a57f6c379ac3 Gogo > shell before was lacking major features like history and coloring but I > think they are being worked now. Also the base libraries are used in other > things I use like the jline and the scala shell. I would love to see > additions and bug fixes going back to the same sources. > > On Wed, Apr 27, 2016 at 12:44 PM, Jean-Baptiste Onofré <[email protected]> > wrote: > >> I don't see how it can work. >> >> If you deploy in pure felix, you won't have the Karaf command "benefits". >> >> The R6 annotations are not enough to cover all Karaf command features, >> and creating annotations on top of that will work only in Karaf. >> >> The best would be to enhance Gogo directly with Karaf features. But the >> community wasn't receptive when we proposed that. >> >> Regards >> JB >> >> On 04/27/2016 06:39 PM, Milen Dyankov wrote: >> >>> Oh those I can do :) I thought you meant karaf command. So to refine my >>> earlier statement I would like to be able to create a karaf command >>> (with all the custom karaf enhancements) but by using standard R6 >>> annotations and perhaps some custom ones on top of that. So that if I >>> deploy my bundle say in plain Felix it works as regular gogo command >>> but if deployed in Karaf it benefits from the nice Karaf add-ons. >>> >>> 27 kwi 2016 18:32 "Jean-Baptiste Onofré" <[email protected] >>> <mailto:[email protected]>> napisał(a): >>> >>> What I already test is not really Karaf command, but more Gogo >>> command (so with limited feature compared to pure Karaf command) >>> (using the shell-compat feature). It worked fine. Let me find it out. >>> >>> Regards >>> JB >>> >>> On 04/27/2016 06:21 PM, Milen Dyankov wrote: >>> >>> Do you happen to have an example? >>> >>> 27 kwi 2016 18:20 "Jean-Baptiste Onofré" <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> napisał(a): >>> >>> >>> We created such annotations to simplify the way to create >>> commands. >>> >>> It's possible to use DS to create the command service, but >>> you have >>> to do some plumbing (service properties for scope, etc). >>> >>> Regards >>> JB >>> >>> On 04/27/2016 05:44 PM, Alex Soto wrote: >>> >>> I ended up doing OSGI lookup, turned out to be more >>> convenient >>> for me, because I needed to handle all services that >>> matched a >>> particular interface, and since I have not used this >>> Declarative >>> Service approach, I lack experience on how to make it >>> work. >>> Thanks to all who helped. >>> >>> Now that my initial problem is out of the way, I >>> wonder why >>> the Command API uses a custom @Reference annotation, as >>> opposed >>> to the seemingly more standard Declarative Service >>> @Reference, >>> specially when the DS version offers a richer set of >>> features. >>> Is it because it would force the service to also use >>> the DS >>> annotations? >>> >>> Best regards, >>> Alex soto >>> >>> >>> On Apr 27, 2016, at 10:21 AM, Jean-Baptiste Onofré >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>> >>> It works if you create another class that contains >>> the DS >>> annotation. Then you can inject into the command. I >>> did it >>> already. >>> >>> Regards >>> JB >>> >>> On 04/27/2016 04:15 PM, Christian Schneider wrote: >>> >>> I fully agree .. normally. Unfortunately I >>> think the DS >>> annotations will >>> not work for karaf commands as they >>> are handled by a custom extender that is not >>> related to DS. >>> >>> A simple solution might be to inject an >>> intermediate >>> internal DS >>> component into the command and do a proper DS >>> service >>> reference in this >>> intermediate. >>> >>> Christian >>> >>> On 27.04.2016 11 <tel:27.04.2016%2011> >>> <tel:27.04.2016%2011>:57, Timothy Ward >>> wrote: >>> >>> Hi Alex, >>> >>> I would strongly recommend using the >>> standard >>> Declarative Services >>> annotations >>> >>> ( >>> https://osgi.org/javadoc/r6/enterprise/org/osgi/service/component/annotations/package-summary.html >>> ) >>> over the Felix or bnd equivalents. >>> >>> Regards, >>> >>> Tim >>> >>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] <mailto:[email protected]> >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >> -- >> Jean-Baptiste Onofré >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > >
