I agree that having to copy the bundles (and other files) before they
get installed is odd (especially as they are copied once more by the
framework). But on the other hand this is imho a minor issue compared to
what we gain.

Let's assume that when using Sling disk space is not that important.

The copying of the files is transparent to the user: a launchpad is
created (either jar or war) which contains everything you want to
install (bundles, configs etc). With this use case in mind it doesn't
play a role if these things are copied, if File Install is used etc. It
just works.

If we would use File Install, we add a well known and used instrument to
install stuff into an OSGi framework. So if people are known and used to
FileInstall, they are already familiar with this stuff. We don't have to
add all the support in Sling - which I think is a good thing; we already
have code for bundles and deployment packages. And imho we really need
support for config files. With using FileInstall we just reuse code.
Code which is developed and used by a much wider base.

With using File Install and copying stuff to a well defined directory we
enable other use cases. If people want to deploy or remove stuff at
runtime, they can just drop/remove stuff from this directory.

There are other scenarios possible where for example the launchpad app
does not contain all the bundles anymore, but they are picked up by File
Install etc.

So in short :) I don't see any downside of this except the disk space -
but I see several advantages.

Regards
Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

Reply via email to