On Nov 24, 2011, at 10:05 AM, Karl Pauls wrote: > I like the idea. I think Marcel added a new endpoint anyways which > allows to hook other kind of provisioning mechanisms (we use it to > create pojosr jars - a single jar that runs a bunch of bundles and > configurations without the need to create any files on disc and > skipping classloader magic). That might be already what is needed to > use the sling osgi installer .... Marrs?
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. 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. Some further comments and questions in-line below: > On Thu, Nov 24, 2011 at 8:54 AM, Carsten Ziegeler <cziege...@apache.org> > wrote: >> I'm wondering what the general opinion about using the Sling OSGi >> installer in ACE is? In general, let's explore this! >> The installer is not tied to Sling it just happens that we have >> developed it as part of the project. It's a general purpose installer >> which ootb is able to handle bundles and configurations like >> FileInstall. The main difference is that we separated the actual >> handling of the artifacts from the providers. So the installer itself >> is handling installation, update, and removal of artifacts and there >> are different plugins providing those artifacts. 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? >> One of these plugins is a file provider (which basically works like >> FileInstall), another one (different bundle) reads artifacts from a >> JCR repository and so on. Ok. >> In addition, the installer handles retries, keeps state of what it did >> install and detects if a user did some manual changes. For example, >> you install bundle A in version 1.0 through the installer, the user >> updates this bundle to version 1.1 through the web console. Now you >> remove the 1.0 artifact from the directory. In this case, the 1.1 >> version should still be active and not be uninstalled. And so on. Interesting. Does that mean that manual changes are always preserved, and override automatic updates? Does this also mean that, like with deployment packages, you can only install one single version of a bundle A at a time? 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). >> Oh, and like with FileInstall it's possible to add support for other >> artifact types. For example we have support for deployment packages >> etc. 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). Greetings, Marcel
