The features are installed programmatically, by a separate "installer" bundle. The karaf feature repo file is generated and saved in the persistent storage area of that installer bundle. In our application, it's possible that a bundle with the same name and version, but with different content gets re-installed. Currently, this is not a problem, since we find the bundle, uninstall it, and re-install it using feature:install and a “disposable” feature repository.
If we can't remove the feature repo, then if we need to reinstall a bundle, we need to find the feature repo that was used to install it, and remove that repo. If we wouldn't, then we would have 2 feature repos which contain the same feature, which doesn't seem like a good idea. While this is not impossible, it's more complicated than our current solution. The point is that we don't really “need” a persistent feature repository, we can easily regenerate the feature repository file when we need to reinstall a bundle. A system that can regenerate data is usually simpler than a system that needs to keep track of that data, making sure it stays in synch, is backed up, doesn't get removed etc... Using Karaf features to install bundles is very convenient for us. We have URLStreamHandlers in place to handle file:, ftp:, and scp: protocols, which means we can easily install bundles from remote locations. The bundles that need to be installed are very light-weight, they are not much more than a wrapper around an Ant script, with a blueprint descriptor that registers it as an OSGi service. This allows us to run a reusable, versioned Ant script on a remote system.While this Ant script is in development, it will be repackaged into a bundle and redeployed to the remote systems. Hence the need to re-install a bundle with the same name and version. I can see the need for tighter rules on features, certainly for consistency’s sake, but we were happier with the more “relaxed” approach. I don't have enough knowledge of Karaf or OSGi to propose a solution, but I hope to make the case to allow less strict rules in certain cases. Thank you very much for your swift reply, Frank 'S Jegers. -- View this message in context: http://karaf.922171.n3.nabble.com/Problems-after-removing-a-feature-repository-in-Karaf-4-0-tp4048979p4048988.html Sent from the Karaf - User mailing list archive at Nabble.com.
