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
