+1 Uninstalling dependent features is a feature we also reeeally need some times. Now, most of our deployments and provisioning starts by simply removing karaf from disk completely and start fresh with unzipping a new copy. Or simply removing the data directory and start over. Regards Björn On Nov 25, 2011 9:36 PM, "Jean-Baptiste Onofré" <[email protected]> wrote:
> Hi Uwe, > > first of all, thanks for using Karaf and sharing your experience ;) > > See my comments inline: > > 1. The ability to "install" a configuration is a great thing, but >> currently >> only new configurations are installed. So if a configuration for a given >> PID >> exists, it isn't touched. >> For us it would be very helpful to be able to extend an existing >> configuration by merging the new properties of a config-feature to the >> existing configuration. >> For example: >> The initial configuration looked like: >> <feature name="config-feature" version="1.0"> >> <config name="sample.conf"> >> prop1=value1 >> </config> >> </feature> >> >> The updated configuration could be: >> <feature name="config-feature" version="1.1"> >> <config name="sample.conf"> >> prop1=value1 >> prop2=value2 >> </config> >> </feature> >> >> So if you install config-feature/1.0, uninstall it and install >> config-feature/1.1, prop2 will not be set/initialized in CM, since >> "sample.conf" is existing. >> >> It would be very nice if the config-installer would be able to process the >> existing configuration and at least adds properties that are not existing. >> Possibly the behaviour of the config-installer could be influenced by an >> extension to the "config"-tag. Something like >> <config name="sample.conf" mergeconf="yes/no/overwrite"> >> would even allow the complete overwriting of an existing configuration. >> > > A similar behavior exists if you use <configfile/> instead of <config/>. > With <configfile/>, if the final configuration file already exists, you > can set an attribute to override existing configuration. > Regarding the <config/> tag, it makes sense to have something similar. > If overwrite is easy to do, merge could be tricky. > Anyway, I'm gonna raise the Jira for that, as it could be an interesting > and logic enhancements for Karaf 3.0. > > >> >> 2. The feature-definitions open the ability to "chain" to installation of >> features by defining dependend features. So you could install a "main" >> feature that includes all features you need to run your application. If >> you >> install "main" all the defined and needed features are installed >> (recursively). >> But when you uninstall the "main" feature, all other features (referenced >> in >> "main") aren't touched and are kept installed and each of them has to >> uninstalled "by hand". >> > > True, it's the expected behavior as a dependent feature could be installed > "outside" the main feature. > > >> So an extension like "features:uninstall -r main" would be helpful that >> uninstalls all dependend features recursively just like "features:install" >> does for installing features. >> I am aware of the fact that this not exactly the way features should be >> used >> and that it is much more complex than described (look up features already >> installed, etc.), but such an extension would make life much more easier. >> > > The -r (as recursive) option could be interesting on a feature. I'm OK to > be an option, and raise a warning to the user that use it, as it could be > very very dangerous ;) > > > Regards > JB > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
