Here's the work around I came up with so far: We add a new feature called the 'karaf-extender' to the featuresBoot.
When started, the extender will load all of the '*.boot' files found in 'etc/featuresBoot.d/'. These files are expected to contain lines with feature references like: foo bar/1.0.0 engine-x/1.0.0 wait-for-kar=my-plugin In the first two cases, we simply invoke FeaturesService#installFeature. In the last case, the feature install will be delayed until the specified Kar is installed (i.e. the name is returned when calling KarService#list). Given an existing Karaf installation, users can then do something like: cp my-plugin.kar $KARAF_HOME/deploy/ echo 'engine-x wait-for-kar=my-plugin datasource-bar wait-for-kar=my-plugin' > $KARAF_HOME/etc/featuresBoot.d/my-plugin.boot and have the features installed on subsequent starts (even when $KARAF_DATA/cache and/or $KARAF_DATA/kar is wiped). Best, Jesse On 2018-11-06 9:19 PM, Jean-Baptiste Onofré wrote: > Indeed, it's not possible right now using a single kar. > > I would do using several kar or directly using features. > > Where would you define the list of installed features for a given kar > (as it's specific to a kar) ? > > Regards > JB > > On 07/11/2018 06:14, Jesse White wrote: >> 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 >>>>>> >>>>> >>> >
