It's already possible via cap/req in features (as we do in Pax Web for instance).
Regards JB On 08/01/2019 13:50, James Carman wrote: > I see the changes in the ActiveMQ to make it more “open” (didn’t know that > was what it’s called). I like that much better. Too bad we can’t declare a > requirement on another repository and not a full import. Perhaps we can > enhance the feature repository format to allow for that? > On Tue, Jan 8, 2019 at 7:37 AM Jean-Baptiste Onofré <[email protected]> wrote: > >> Hi James, >> >> I guess you mean "open" features (where features repo are used at >> runtime) compared to "close" features (where features repo uses inner >> <repository/>). >> >> The approach also depends of your deployment option. For instance: >> >> 1. when I'm using Karaf as a runtime, where I install several >> applications, most of the time I'm using "open" features (via Cave >> Feature Gateway or directly). >> 2. when I'm using Karaf more as an immutable "box" (like on Docker), >> "close" features or custom distribution is convenient. >> >> Generally speaking, I prefer "open" features repo, and eventually create >> my own custom distro (as the "kloud" one). >> >> Regards >> JB >> >> On 08/01/2019 12:42, James Carman wrote: >>> I’m really not a big fan of features files pulling in karaf feature >>> repository files. We avoid that at work and just have our features files >>> refer to other features by name only (no versions and no repositories). >>> That’s a more controlled environment, of course. What’s the “best >> practice” >>> for the more general care? It just seems dangerous for other folks to >> start >>> yanking in possibly incompatible feature repositories. >>> On Tue, Jan 8, 2019 at 1:59 AM Jean-Baptiste Onofré <[email protected]> >> wrote: >>> >>>> Hi, >>>> >>>> AFAIR, I already fixed ActiveMQ features XML. >>>> >>>> Let me try with ActiveMQ SNAPSHOT. >>>> >>>> Regards >>>> JB >>>> >>>> On 08/01/2019 07:35, Benjamin Graf wrote: >>>>> Hi JB, >>>>> >>>>> that's the error of the ActiveMQ feature file I reported last year. The >>>>> corrected feature file is not releases yet. It may also be a problem in >>>>> the resolvement algorithm used by involved components mainly outside >>>>> Karaf I think pax-url if I remember right. >>>>> >>>>> Regards >>>>> Benjamin >>>>> >>>>> Am 8. Januar 2019 06:09:10 MEZ schrieb "Jean-Baptiste Onofré" >>>>> <[email protected]>: >>>>> >>>>> By the way, the enterprise features repo is used in the standard >>>> Karaf >>>>> distribution, so it's weird that it works here. It's maybe a >>>> combination >>>>> of features. >>>>> >>>>> For the tracking I created: >>>> https://issues.apache.org/jira/browse/KARAF-6075 >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> On 07/01/2019 22:16, James Carman wrote: >>>>> >>>>> We are trying to build our own custom Karaf 4.2.2 distribution >>>> and >>>>> when we include the enterprise feature repository along with >> the >>>>> ActiveMQ 5.15.8 feature repository, we get an invalid >>>>> org.apache.karaf.features.cfg file which includes >> 4.2.3-SNAPSHOT >>>>> versions of some of the boot features. I have created an >> example >>>>> project here: >>>>> >>>>> https://github.com/jwcarman/custom-karaf-example >>>>> >>>>> If you build it as-is, you'll see the problem. If you comment >>>>> out the >>>>> enterprise feature repo, the problem goes away. >>>>> >>>>> Thanks, >>>>> >>>>> James >>>>> >>>>> >>>>> -- >>>>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. >>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> [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 >> > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
