The problem is that the current scheme doesn't handle the case where the 
launchpad JAR is updated in a consistent manner. Whenever this is raised, the 
answer is to deploy bundles via sling:install or the web console. In my 
experience, this technique just doesn't scale past a single node. Perhaps Ace 
is a better answer for this, but I think updating the JAR should have a 
consistent effect.

It is my belief that the only way to fix this situation is by loading bundles 
from VFS layer we have rather than extracting the bundles. I could (of course) 
be wrong about this and I have not prioritized this (I've got a set of 
RightScripts which will get me by in the near term).  But my fear is that by 
removing the code you're suggesting we remove, fixing this issue becomes that 
much harder. 

> 
> 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.

At minimum, I'd like to see us recommend against doing this. If we need to 
extract files from the archive, let's do that in a directory where we tell 
users not to touch and then create a 'dropins' directory for user-managed 
files. If users manipulate the extracted files, things can go haywire when 
Launchpad decides to re-extract the archive.

> 
> 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.
We already have an alternate scenario - launchpad:run and launchpad:start use 
bundles (OK, artifacts) from the local Maven repository. And now that Aether 
has been released, I'm going to start experimenting with this in Launchpad 
itself.

If you can give me about 10 days, I'll have a different ConfigAdmin solution.

Sorry to be a stick in the mud about this.... 

Justin

On Aug 9, 2010, at 11:38 AM, Carsten Ziegeler <cziege...@apache.org> wrote:

> 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