Agreed, using the MANIFEST won't get us much further. We already have a custom Karaf distribution and are looking to provide extensions (i.e. plugins) as .kar files which be added to existing installs.
Some of these .kar files will contain many features, and we're looking for a means to control which of these are installed *outside* of the .kar files. Otherwise we'll end up having to manage and distribute many .kar files with all the different permutations of the feature sets. For example, let's assume that the features in the .kar file include: <feature name="datasource-foo" version="1.0"> ... </feature> <feature name="datasource-bar" version="1.0"> ... </feature> <feature name="engine-x" version="1.0"> ... </feature> <feature name="engine-y" version="1.0"> ... </feature> Using the single .kar file, we would like to allow users to install datasource-foo & engine-x, or datasource-bar & engine-y and so on... I suspect there's no way to do this currently, but I would happy to provide a patch upstream if we could find a good way to solve this. So far I've resorted to using the following approach: https://github.com/OpenNMS/opennms/blob/5769a2a009da21849360e554b61756fd227ab72b/container/extender/src/main/java/org/opennms/karaf/extender/KarDependencyHandler.java Best, Jesse On 2018-11-06 8:52 PM, Jean-Baptiste Onofré wrote: > Hi, > > In that case, kar doesn't support it for now. I can create a Jira and > extend the MANIFEST to have a list of startup feature but I'm afraid we > will end with what we already have with features. > > Why not using directly the features XML ? > > A KAR is basically a Maven repository packaged as a zip file. You can > directly use repositories in Karaf. > The resources can be added in the Karaf system repository (in a custom > distribution for instance), or you can add your own repository as KAR > service does. > > Regards > JB > > On 07/11/2018 05:45, Jesse White wrote: >> Thanks for the reply JB. >> >> We'd like to control which features are installed outside of the >> features XML. >> >> The reason for this is that there are many features available, but we >> want to give the user control on which ones to install. In our case, >> there are just too many possible permutations to provide a different >> .kar artifact for each "feature set". >> >> Thanks, >> Jesse >> >> On 2018-11-06 8:38 PM, Jean-Baptiste Onofré wrote: >>> Hi Jesse, >>> >>> You can use the install attribute on the features XML: >>> >>> <feature name="foo" version="1.0" install="auto"> >>> ... >>> </feature> >>> <feature name="bar" version="1.0" install="no"> >>> ... >>> </feature> >>> >>> only the feature with install="auto" will be installed when you deploy >>> the kar file. >>> >>> Regards >>> JB >>> >>> On 07/11/2018 00:09, Jesse White wrote: >>>> All; >>>> >>>> We're interested in leveraging .kar files to help package plugins and >>>> extend our platform but we've run into a snag. >>>> >>>> If a .kar file contains many features and we want to let the user >>>> control which feature(s) to install, is there a way to have these >>>> features installed automatically on a clean start? >>>> >>>> So far we've tried setting 'Karaf-Feature-Start=false' in the .kar files >>>> manifest to prevent *all* of the features from being automatically >>>> installed. User's can then configure and install the features they need, >>>> but there doesn't appear to be a built-in way to make these persist >>>> after a clean start. >>>> >>>> Normally we would use the 'featuresBoot' property for this, but in the >>>> case of a clean start it appears that the .kar and the feature >>>> repository defined in the .kar are not yet available when these >>>> statements are processed. >>>> >>>> I'm wondering if there's a way around this that we're not aware of. If >>>> there isn't, is there any interest in solving this use case directly in >>>> Karaf? >>>> >>>> There are some more details on our use case and what we've tried here: >>>> https://issues.opennms.org/browse/HZN-1436 >>>> >>>> Thanks, >>>> Jesse >>>> >>> >
