Features...

[ra...@enjekt.org]

Sorry about sending this on a separate reply but I have issues with Gmail
and my reply address bouncing when I reply to any of the Camel and Karaf
forums. I've virtually given up trying to post replies to folks issues on
the Camel forum anymore. 

 

I commonly separate them out for database setup, transaction services, etc.
I might be working on the functionality of a bundle or group of bundles and
during development I just want to install/uninstall a single feature and not
the whole ball of wax. But for initial deployment or deployment on a server
I want the single target. 

 

Occasionally I blow away the cache and delete any cfg files and reinstall
the entire application. I do that as much to make sure I'm not fooling
myself as when I'm modifying cfg files or configuration or features and I
want to make sure that my changes are really working and not picking up old
artifacts. Perhaps there's a better way to do this. I'll just make up a
simple case though to illustrate.

 

When I'm setting up and debugging, I can install the features one at a time
and make sure that everything is found and working. If any errors pop up, I
can fix the feature and re-run it. When they are all running, I'm good.  In
the below example, I might be working on the foo-transaction-services and
adding new SCR connectors. I'd like to be able to unzip a new copy of Karaf
or blow away the cache and my cfg files, run the foo-test-all and have
everything up and running.  Then as I monkey wrench the transaction services
I'd like to uinstall/reinstall the foo-transaction-services feature and have
the bundles removed along with configuration and then have them reinstalled.
Obviously, it sounds as if that would be too different. It might look more
like a fork directive or script than the collection of features. 

 

<feature name="foo-all" version="${project.version}">

              <feature>foo-core</feature>

              <feature>foo-datasource</feature>

              <feature>foo-transaction-services</feature>

              <feature>foo-netty-server</feature>

              <feature>foo-rest-services</feature>

       </feature>

 

       <feature name="foo-test-all" version="${project.version}">

              <feature>foo-all</feature>

              <bundle>foo-test-dbloader<bundle>

       </feature>

 

More akin to:

 

<feature name="foo-all" version="${project.version}">

              <feature fork=true>foo-core</feature>

Or more like.where there isn't an implied parallelism. 

              <run:feature>foo-datasource</run:feature>

              <feature>foo-transaction-services</feature>

              <feature>foo-netty-server</feature>

              <feature>foo-rest-services</feature>

       </feature>

 

The atoms would retain their individuality that way. It might be that a
different kind of feature like feature-container would be a possible
mechanism. Dunno. Just thought I'd ask because it fits my works style with a
lot of unit tests and then iterations into both a clean and dirty container.

 

From: jbonofre [via Karaf] <ml+s922171n4055049h40@n3.nabble.com
<ma...@n3.nabble.com> > 
Sent: Monday, February 4, 2019 2:44 PM
To: Ranx <ranx@enjekt.org <ma...@enjekt.org> >
Subject: Re: Features install options...

 

Hi Brad, 

see my comments inline: 

> 
>  1. Is there a directive to tell Karaf to run the features installs 
>     individually and not to lump them together? 

Why not splitting your feature in features, and then you can do 
feature:install ? I'm not sure I understand what you mean ;) 

>  2. Is there any directive to tell Karaf to delete/remove any 
>     configuration files it has installed when it uninstalls the feature 
>     associate it with it? 

Not currently (for "security" reason on the config). You can override 
the cfg files at install time. 
I can create a Jira to add an option to cleanup file based on 
<configfile/> finalName. 

>  3. In the past I've used the plugin to install .cfg files from my 
>     bundles and there is a directive override=true/false. Does anything 
>     like that exist for the config done directly from the feature? 

I guess you mean <config/> element. No, <config/> element is for 
ConfigAdmin, it's created at feature install time. 

Regards 
JB 

  _____  

If you reply to this email, your message will be added to the discussion
below:

http://karaf.922171.n3.nabble.com/Features-install-options-tp4055048p4055049
.html 

To start a new topic under Karaf - User, email
ml+s922171n930749h40@n3.nabble.com
<ma...@n3.nabble.com>  
To unsubscribe from Karaf - User, click here
<http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscrib
e_by_code&node=930749&code=cmFueEBlbmpla3Qub3JnfDkzMDc0OXwtMzQzMzI3NTk4> .
 
<http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_view
er&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNa
mespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.No
deNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_ema
ils%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> NAML