You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ace.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2011/10/04 18:26:23 UTC
Client :: AutoDeploy
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.
The developer (it's only useful during development time after all) can
add that feature to a distribution which can then be deployed to targets.
That way, a build system can just put new bundles into a directory and
they automatically get deployed to any application instance that is
"connected" to the observed folder.
I've done some research today to understand the client API and I think
that should be possible. Does that make sense? Is that something that
you think would be a good addition to ACE maybe? Maybe "AutoDeploy" is
not the best name.
Jeremias Maerki
Re: Client :: AutoDeploy
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Jeremias,
On 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.
That would work.
One thing to think about is when exactly to commit the changes. ACE makes updates transactional. Typically file install acts on any change it sees. I know it has heuristics for determining when a change is still in progress (a file being copied, new files showing up in a folder) but this is still a big of guesswork. Not crucial during development though: if an update gets split in half, we just wait for the other half to arrive and then try again.
Depending on the IDE or build system, you could perhaps make the "commit" an explicit action (at the end of the build cycle of your script or triggered by some "on build succeeded" trigger in an IDE).
> The developer (it's only useful during development time after all) can
> add that feature to a distribution which can then be deployed to targets.
> That way, a build system can just put new bundles into a directory and
> they automatically get deployed to any application instance that is
> "connected" to the observed folder.
That would be a great integration!
There are a few things to think about here:
1) For ACE, any new bundle needs a new version, if BSN+version are identical, ACE assumes it's the same bundle, so there's no support for magic names such as "snapshot" versions. This is not hard to solve though, usually we add a qualifier to the version that contains a datestamp in a sortable string format.
2) For an OBR, each file needs a unique name. A lot of build systems simply overwrite the same file (so a bundle with a BSN+version might be called <BSN>.jar where for OBR <BSN>-<version>.jar would be better.
3) If you run ACE on your local machine, you can get away with using local file:/// URLs for your artifacts and can skip copying them into the OBR (except that maybe for solving #2 above you might need to make a copy anyway).
> I've done some research today to understand the client API and I think
> that should be possible.
Definitely.
> Does that make sense? Is that something that
> you think would be a good addition to ACE maybe?
Yes and yes!
> Maybe "AutoDeploy" is not the best name.
Agreed, but I don't have a brilliant suggestion yet for a better name. Anyone else? :)
Greetings, Marcel
Re: Client :: AutoDeploy
Posted by Marcel Offermans <ma...@luminis.nl>.
On Oct 5, 2011, at 9:14 AM, Jeremias Maerki wrote:
> 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
> application.
We did start some discussions about "unifying" schedulers in the past. I just don't think we finished that discussion and followed up on it. From memory, the Sling scheduler is based on Quartz. I remember the biggest issue with that is that our management agent also needs a very simple scheduler, and that we did not want to deploy Quartz because it was way too heavy.
That does not mean the idea is bad. In fact, if we can come up with an API for a scheduler that is generic enough to support both a very lightweight version (for our management agent) and a more sophisticated one (for "enterprise" environments) that would be great. The trick is to find a way to combine the richness of the Quartz API with the "lean and mean"-ness of a very lightweight implementation.
Apart from coming up with the API it will probably then require some effort to adapt Sling and ACE to this new API. And while we're at it, we might also want to send a copy to the OSGi Alliance so they can include it in the OSGi Compendium.
Greetings, Marcel
Re: Client :: AutoDeploy
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Jeremias,
On Wed, Oct 5, 2011 at 9:14 AM, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> ...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...
Ok, I see, thanks for the clarification! Just wanted to mention the
Sling stuff as it has some similarities.
-Bertrand
Re: Client :: AutoDeploy
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
application.
On 05.10.2011 08:26:27 Bertrand Delacretaz wrote:
> Hi Jeremias,
>
> On Tue, Oct 4, 2011 at 6:26 PM, Jeremias Maerki <de...@jeremias-maerki.ch> 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] http://sling.apache.org/site/jcr-installer-jcrjcrinstall-and-osgiinstaller.html
> [2] http://svn.apache.org/repos/asf/sling/trunk/installer
Jeremias Maerki
Re: Client :: AutoDeploy
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Jeremias,
On Tue, Oct 4, 2011 at 6:26 PM, Jeremias Maerki <de...@jeremias-maerki.ch> 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] http://sling.apache.org/site/jcr-installer-jcrjcrinstall-and-osgiinstaller.html
[2] http://svn.apache.org/repos/asf/sling/trunk/installer