Karaf 4 is very modular and uses its own feature definitions to build distributions and has very few requirements. You can even use the features service to build "static" distributions for micro-services. There's no such concept of "full karaf" anymore with Karaf 4, there's only a default distribution which comes with pre-installed features.
The features service bundle depends on 3 packages which are not provided by the system bundle: org.slf4j, org.osgi.service.cm, org.ops4j.pax.url.mvn. We even use the service outside of OSGi during the maven build. Worst-scenario, you can build your own bundle on top of it, embed the code you need and get rid of unwanted dependencies. The way it works is the following: * you define requirements (which can be on Karaf features, or any kind of requirements) * karaf features provide possible bundles to solve those requirements (but you could use a Repository, even though those needs to be used with great care) * you launch the features service which will : compute the new wiring, compute the actions to perform to go to it (uninstallation, installation, refreshes, etc...), and apply those actions. And I agree with Peter, it's quite difficult to implement correctly, so I definitely would not recommend rewriting such a thing from scratch, unless you have quite some time to spend on it. 2016-06-15 13:29 GMT+02:00 Paul F Fraser <pa...@a2zliving.com>: > Hi Guillaume , > > Are the Karaf features usable without full karaf, i.e. Standalone ? > > Paul > > > On 15/06/2016 9:24 PM, Guillaume Nodet wrote: > > Yes, that's perfectly doable. > We've implemented that in Karaf 4.0. You need to use karaf features for > that. Bundles will be uninstalled when no longer required in a very > reliable way because it uses the OSGi resolver to actually compute the > wiring. > > Guillaume > > > 2016-06-15 13:18 GMT+02:00 Paul F Fraser <pa...@a2zliving.com>: > >> Thanks Marcel, Neil and Peter, >> >> From Peter's comment >> >> "I think it is incredibly hard to do this reliably with the extensive >> requirement capabilities of OSGi" >> >> Is this why Aries subsystems have a phase where bundle versions are >> locked in for deployment of the subsystem? >> >> Paul >> >> >> >> > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- ----------------------- Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
