karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: featuresBoot & .kar files
Date Wed, 07 Nov 2018 05:19:28 GMT
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message