2011/11/24 Marcel Offermans <marcel.offerm...@luminis.nl>: > Let me start by explaining this in a bit more detail (while I'm trying to > understand exactly how the Sling installer works): > > At a high level, ACE consists of a server and a management agent running > within the target OSGi container. The management agent first asks the server > about available versions of the software, and if there's something new, the > next request it sends is to actually get this new version. > > The response from the server now by default is a Deployment Package that > either contains the delta of artifacts between two versions, or a full set of > artifacts. Within that deployment package, artifacts have a type, and for all > non-bundle types, a resource processor is also shipped as part of the package. > > On the server side we have a mechanism now that allows us to literally "post > process" that deployment package and transform it into something else. Like > Karl says, we've used that to create PojoSR JAR files (just as a proof of > concept for now) but that shows we can do all kinds of transformations on > them. > > I can see a couple of ways to integrate the Sling installer into ACE: > > 1) You state that the Sling installer already supports Deployment Packages. > That actually means that it could just fetch one from the ACE server and > install it. That sounds like the easiest solution and would probably require > only very little modifications to the installer. Yes
> > 2) Create a post processor that transforms a deployment package into > something else that is more suitable for the Sling installer, and have that > installer "fetch" that something and install it. We now fetch everything in > one go, so I'm not sure how that would map. > > 3) Create a post procesor that transforms a deployment package into a fully > self-contained installer that contains both the installer itself and the > actual set of artifacts (this would be similar to our PojoSR experiment). It > does not necessarily cater for updates this way, but it would be a very > convenient way to bootstrap using a single, executable jar file. I'm not sure if I can follow you for the last two points :) I haven't looked at latest ACE yet, but my understanding was that it's possible to deploy other artifacts than deployment packages (at least in theory maybe). So are you saying, these are always transferred as deployment packages and then transformed into the "correct" artifact on the client installing this stuff? This would be possible with the Sling installer as well as we have the concept of transformers. If something else is than a deployment package is transferred this can be directly installed by a plugin. > > Conceptually, this is very close to what the ACE management agent does, with > perhaps the difference that we use Deployment Admin as the basis and that > that spec defines a single package that contains both the artifacts and the > handlers. On the target side, we send artifacts to handlers as well to > physically install them, and this is done in the context of a session or > transaction that also supports rollback. > > Having the Sling installer as an "alternative" management agent sounds like > something we should look at supporting. > > We could even look at if we can bridge the Sling handlers to/from Resource > Processors to/from File Install plugins. However, I know that at least File > Install does not know how to deal with sessions/transactions and rollback > changes if something went wrong. How is that for the Sling handlers? We don't have a rollback mechanism but a retry - so the basic idea is - if something is about to be installed, it really should be tried as hard as possible. So if an install fails, the installer retries it, after something else has been installed. So for example, if a bundle is missing during the first try, and this one gets installed later, the installer retries and everything is fine. On the other hand, the Sling installer is able to do a rollback if the artifact disappears from the provider. > > Interesting. Does that mean that manual changes are always preserved, and > override automatic updates? Yes. > Does this also mean that, like with deployment packages, you can only install > one single version of a bundle A at a time? Yes. > In the context of ACE and Karaf features, we ran into an issue that for > example, if you have an installation that includes bundles: > > * A 1.0 > * A 1.1 > > and you then create a new version that contains: > > * A 2.0 > * A 2.1 > > that you cannot detemine which is an update of which. OSGi simply does not > provide enough metadata for that. For now we have no solution for that yet > (Karaf simply does not support updates at all, but to me that is not > acceptable since that means loosing your bundle data area). These are packages containing the same bundle in different versions? > > Are those plugins for File Install part of Sling? I am wondering where we > should collect them (in the context of Bram's mail about his contribution to > Felix). Right now we have everything in the Sling SVN. Like Bertrand said, I see no problem in giving others commit for Sling to work on this. We could also move the installer to Felix or somewhere else. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
