Yes, Cave is a good option, especially with the last Cave Deployer feature included by JB that is really interesting :)
Le 09/07/2018 à 21:29, Nicolas Brasey a écrit : > Our ideas is to provide maven repositories for each "application". > These repos should contains features.xml which refers to jars which > are also in the same repos or jars that are already available. I > wanted to leverage the fact that each kar repo is automatically > available as remote repo by the resolver. > > I think Cave is definitely an option but I wanted to avoid the need to > maintain yet another server in prod and potential point of failures. I > wanted to keep it simple for now... > > > > > > On Fri, Jul 6, 2018 at 3:48 PM Guillaume Nodet <[email protected] > <mailto:[email protected]>> wrote: > > > > Le ven. 6 juil. 2018 à 14:56, Nicolas Brasey > <[email protected] <mailto:[email protected]>> a écrit : > > Yes we tried but had problems with the > KarService implementation of karaf v.4.1.2 which had some > issues with starting our features, there was some kind of loop > which ended-up installing/uninstalling many time the same > features, it was not working for us, so we have now our own > implementation of a KarService which only unpacks the kar into > a repository directory outside of the karaf distribution. The > installation of the feature is made manually in a second > stage. So at the moment we use the Kar as only a zip container > as maven repository. > > > So what are you distributing exactly ? Because if you use the kar > deployer, it means you *have* to use a manual step after that > because the features won't be available at boot stage. If you > repackage the application after having installed the kars > manually, you're basically creating a custom distro, else, > persisting something which has not taken place yet won't help... > > > > I saw the implementation of the KarService changed in the > latest version of Karaf, so I've not tried again since. > > Is it possible to tell the karaf feature resolver to persist > the state of the features outside of the karaf distribution ? > This would be helpful for us. > > Thanks, > Nicolas > > > > > > > On Fri, Jul 6, 2018 at 2:34 PM Guillaume Nodet > <[email protected] <mailto:[email protected]>> wrote: > > Have you tried simply dropping the kars in the deploy > folder ? > This should install / start them automatically without the > need to create a custom distribution. > > Guillaume > > Le jeu. 5 juil. 2018 à 13:53, Nicolas Brasey > <[email protected] > <mailto:[email protected]>> a écrit : > > 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 > > > > > > > > > -- > ------------------------ > Guillaume Nodet > > > > -- > ------------------------ > Guillaume Nodet >
