Mailing-List: contact ace-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ace-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of karlpauls@gmail.com designates
 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKkCf4rMJX=-QU9=wtEYsoKB6+J58f=7eX=9TrUNBum=ai4YtQ@mail.gmail.com>
References: 
 <CAKkCf4rMJX=-QU9=wtEYsoKB6+J58f=7eX=9TrUNBum=ai4YtQ@mail.gmail.com>
From: Karl Pauls <karlpauls@gmail.com>
Date: Thu, 24 Nov 2011 10:05:01 +0100
Message-ID: 
 <CAJnwQNjXsZvE33gi-fxK7a_-gf3aWHJPqQGMprFsdc-RUivnaw@mail.gmail.com>
Subject: Re: Using the Sling OSGi Installer?
To: ace-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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?

regards,

Karl

On Thu, Nov 24, 2011 at 8:54 AM, Carsten Ziegeler <cziegeler@apache.org> wrote:
> Hi,
>
> I'm wondering what the general opinion about using the Sling OSGi
> installer in ACE is?
>
> 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.
> 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.
>
> 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.
>
> Oh, and like with FileInstall it's possible to add support for other
> artifact types. For example we have support for deployment packages
> etc.
>
> Just a rough description :)
>
> So, in general, WDYT?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>


-- 
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls