ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: My first impression of ace
Date Tue, 28 May 2013 20:00:26 GMT
Hello Bram,

On May 28, 2013, at 20:21 PM, Bram Pouwelse <> wrote:

> In the last few weeks we've started using ace for a project as an attempt
> to simplify the deployment procedure for one of our applications. And it
> certainly has the potential to do that!
> But the last few days we're doing a lot of "snapshot" releases (remove
> bundle -> store -> purge from repo -> add bundle -> store).
> This does the job but isn't there an easier way to replace a bundle in the
> repo?

We usually take a different approach. In stead of calling everything "1.0.0.SNAPSHOT" we usually
use that last part (the qualifier) to encode a timestamp, so something like "".
In Bnd there is a macro you can use to achieve that:

Bundle-Version: 1.0.5.${tstamp}

ACE assumes that the combination of bundle symbolic name + bundle version is unique, so by
design it does not detect changes if the version remains the same.

The trick you use, does work, and there is no easier version (you can automate the process
a bit more though, by talking to the REST client API from some kind of script (or build task).

> Besides that in the past 2 days ace stopped updating the target. After
> removing a bundle from the artifact list and a "store" the bundle is not
> removed from the target.
> I've tried to fix this by: (no luck)
> - Restarting the ace server
> - Restarting the agent on the target
> - Restarting the target (without clean)
> - Restarting the target in a clean state (this resulted in a target
> without bundles provisioned by ace)
> What did work was removing the contents from the bundle-cache folder, but
> after removing I need to  define features and distributions again.

Just to make sure, after clearing out the cache, you configured exactly the same set of bundles
to be deployed to the target?

In theory there are a couple of reasons why a deployment fails (these are defined in the Deployment
Admin specification) but if you deploy a set of bundles they should consistently work. So
you might actually have stumbled on a bug. Hard to tell without more data.

If this happens again, please save a copy of the bundle cache (and store). You can send it
to me off-list so I can take a look.

> What would be the best way to find out why the target isn't updated
> anymore?

I usually do a couple of things (let's say I have a target called target-1):

1) I validate (with a REST client or within the browser) that I indeed get the correct list
of available versions: http://localhost:8080/deployment/target-1/versions

2) I manually download the deployment package with the highest version (let's say it was 5.0.0):
http://localhost:8080/deployment/target-1/versions/5.0.0 (a deployment package is a jar, and
you can inspect it to see all the artifacts you expect are actually in there)

3) If that looks good, I usually try to add a shell to the target, so I can interact with
it (you can also deploy the Felix WebConsole if you like that better). This allows me to inspect
the target in more detail, and also view the log on the target. I then usually start by just
deploying the shell, and then, as a second step, deploy the other artifacts.

> This was all using the server-allinone jar built from trunk 2 weeks ago,
> today I've updated to the latest version. (then again I needed to remove
> the bundle-cache and my config is gome).

Yes, one of the things we did was change the storage format for the internal repositories.
We now compress them on disk, which saves a lot of disk space.

> Thanks for creating ace!

Thanks for your feedback. Let us know if we can help you narrow down the problems you had.

Greetings, Marcel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message