You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Jesse White <je...@opennms.org> on 2018/11/06 23:09:44 UTC
featuresBoot & .kar files
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
Re: featuresBoot & .kar files
Posted by Jesse White <je...@opennms.org>.
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
>>>>>>
>>>>>
>>>
>
Re: featuresBoot & .kar files
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
Re: featuresBoot & .kar files
Posted by Jesse White <je...@opennms.org>.
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
>>>>
>>>
>
Re: featuresBoot & .kar files
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
Re: featuresBoot & .kar files
Posted by Jesse White <je...@opennms.org>.
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
>>
>
Re: featuresBoot & .kar files
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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