Hi Jean-Baptiste, Yes, our different kars have dependencies, so they must installed in a certain order.
The features.xml only is not possible in our case because our target machines are running on private networks without internet access, so the kars must contain all the runtime transitive dependencies. But to explain exactly what I'm trying to achieve today, I need to explain the history of our solution. It started 3 years ago as a single application, at that time, the dev team A was delivering the app as a turnkey solution with a custom karaf distribution. The installation was very easy for the delivery team => Move the distribution to the server, unzip and start, the application jars were located in the system repository and the app features marked as boot features. Over the last months, we extended the core application by providing plugin mechanisms by using SPI's, implementing the white-board pattern (we like this a lot by the way :)). So now dev team B is implementing different plugins for specific needs. Those plugins have a different life cycle that the core app, and they are released as kars. Lately we found a bug in the main app which needed to be fixed and patched in a prod environment. We provided the patch with a new custom karaf distribution which the delivery installed. Of course, this new karaf distribution used another data directory and did not reinstall the features of the kars of the different plugins. So manually reinstalling the plugin features is absolutely needed in this scenario or the behavior of the application can differ from before the patching, which is obviously dangerous. Like I said, our main application is still released as part of our custom karaf distribution, this should be changed and we will probably release it a kar as well. So I try to achieve 3 things: 1) Find the optimal packaging for our app and plugins so that it can be install / upgraded easily 2) Hide Karaf (OSGi) complexity from the delivery team, and they don't want to know about it :-) 3) Find the optimal way to set the bundle versions in our feature files using ranges What would be a good practice in a scenario like ours? Thanks again. Regards Nicolas On Thu, Jul 5, 2018 at 2:31 PM Jean-Baptiste Onofré <[email protected]> wrote: > Hi Nicolas > > The purpose of boot features is to start in early stage, so it uses the > cfg file as definition. > > In your case, you should use inner and prerequisite feature. > > Do you have some dependencies between kar ? > > Why don't you use directly feature instead of packaging as a kar ? > > Can you explain exactly what you are trying to do ? > > Karaf always store the feature state (in the resolver), so, if you first > install kar1, then kar2, when you restart, the resolver will > reinstall/start those features. > > So, you don't have to use a boot feature: if you don't remove the data > folder, the installed features and repositories are stored. > > Regards > JB > > On 05/07/2018 13:52, Nicolas Brasey wrote: > > Hi all, > > > > I'm trying to find out if there is way to install a feature and make it > > as a boot feature without manually altering the feature cfg file > > (org.apache.karaf.features.cfg). Checking in karaf's code seems to > > indicate there is no way to do this programmatically. > > > > Ideally, it would be a flag in the feature:install command to indicate > > to add this feature as a boot feature. > > > > The reason we need this is that our solution is an integrated solution > > which is delivered by different departments: > > > > 1) Product 1 (kar 1) => dev team A > > 2) Product 2 (kar 2) => dev team B > > 3) Integration layer (camel routes essentially) (kar 3) => integration > team > > > > All these different teams delivering a self contained kar file with a > > feature which should be installed and started when karaf starts in order > > to have the global solution running. > > > > We are using karaf v.4.1.2 which does not seems to persist which > > features have been installed (only the boot features). I'm not sure > > about the v.4.2.x... > > > > I know Karaf since not so long, but I believe Karaf has been designed so > > that the delivery team is supposed to create a Karaf distribution and > > assembling the required boot features at build time. If this is true, > > then it is not ideal according to how our internal process is made. > > > > Any thoughts? > > Thanks! > > > > Best regards, > > Nicolas > > > > > > > > > > > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
