Another option, the one I would prefer, create your own distribution. It's pretty straight forward, create a features.xml of your bundles and the ones needed. Now create another project using this features xml and the features-maven-plugin with the add-features-to-repo goal. Now you are able to assmbly your own distribution, see also [1].
regards, Achim [1] - http://karaf.apache.org/manual/latest-2.3.x/developers-guide/custom-distribution.html 2012/10/23 Urppa <[email protected]>: > I'm working on an application that has roughly 6-8 OSGi-bundles written by > us. Then we have around 40-50 OSGi-bundles as dependencies from our bundles. > > Our application environment will be internal network with no internet > access. The Karaf-instances hosting the application will be running in quite > restricted virtual machines that access database(s) and offer > JMS/RMI/SOAP-endpoints for the clients. I don't think we will be able to > setup any maven repositories. > > We do need to update the application from time to time and the application > is pretty mission critical, needs to be running with 99.999+ availability. > > Currently I'm thinking that to update the application we would use parallel > Karaf-instances. Something like "APPv1" as the initial child instance; and > if we need to make some update/fix, we would create a new instance, like > "APPv2" and then deploy all the new stuff there, bring it into production > (with different endpoint addresses so it can co-exist for a short while with > the APPv1) and then change all clients to use the new version and then > shutdown and destroy the old version. > > So, what would be the best practise to deploy this application? > > My thoughts: > - The quick'n'dirty way would be to just copy all jar-files to the > Deploy-folder of Karaf. This doesn't feel very manageable wrt versioning and > packaging. We need to be very exact wrt versions. Prolly works ok for > development. > - Create a KAR-file and make one "feature" of the application and include > all dependencies inside the KAR-file. > - Create a single jar-file and embed all dependencies into it. > > Currently the KAR-file feels like a way to go. But how about the concept of > "feature", it feels like some "extension" into Karaf and not really an > "application". But is it just semantics; would a feature from a KAR-file be > as "real" of an application as any other application deployed as plain > jar-files? Would our app lose any services/functionality of Karaf/OSGi if it > would be deployed as a "feature" from KAR-file? > > All comments/ides are highly appreciated. > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Best-practise-for-deploying-my-app-with-Karaf-tp5721452.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
