ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <>
Subject Re: Client :: AutoDeploy
Date Wed, 05 Oct 2011 07:14:05 GMT
Hi Bertrand

Thanks for the pointer. But I'm not installing bundles (and other
artifacts) in a framework. I'm putting them in an artifact repository. I
see how I could add additional tasks that would put bundles in the
repository rather than in the framework. But I'd have to find out how to
make sure the framework installer task is not run for a bundle. The
Sling installer seems to be quite a rather complicated beast. Much more
complicated that what I need here. FileInstall's scanner does all I need
to handle changes in the directory. The biggest task is simply to write
the code that interacts with the repository. I think I'd trade very
little functionality duplication with a lot of complexity due to using
the installer, especially when I have to tweak it to the present use
case first. I can't afford to invest that much time. What I'm writing
here is just a development-time tool.

What I think would be beneficial to ACE is to adopt Sling's scheduler
which is more flexible than the one here. I'm already using it for my

On 05.10.2011 08:26:27 Bertrand Delacretaz wrote:
> Hi Jeremias,
> On Tue, Oct 4, 2011 at 6:26 PM, Jeremias Maerki <> wrote:
> > I've explained earlier what I'm looking around for. So I've been
> > thinking about an "AutoDeploy" bundle which reuses FileInstall's Scanner
> > class that oversees a local file system folder.
> >
> > Whenever a local artifact is added, updated or removed, it synchronizes
> > it with the ArtifactRepository. When an artifact is added or removed it
> > is also added or removed from a group/feature that's configurable. After
> > each synchronization, the changes are committed....
> Note that we're doing something very similar in Sling, where bundles
> and other artifacts found in the JCR repository or filesystem are
> automatically installed, upgraded or uninstalled. This is based on a
> modular installer (which takes care of OSGi operations) and providers
> (which detect and supply new or modified resources).
> You might find some possible synergies or reusable components -
> there's some (out of date as far as I can tell) documentation at [1]
> and the code and integration tests are at [2].
> Maybe this helps...
> -Bertrand
> [1]
> [2]

Jeremias Maerki

View raw message