Hello Bram,
On May 28, 2013, at 20:21 PM, Bram Pouwelse <[email protected]> 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 "1.0.0.20130528212600". 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
