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 >>>>> >>>> >> -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
