So you quite end up with a single deployment package for a given container which is updated when you want to deploy something else. Though it works, I don't really see the benefit of the deployment admin (it kinda becomes an implementation detail) ... The other problem is that you need to exactly control the state of the framework in order to make any deployment, so that the same "application" can not be easily deployed onto multiple containers.
On Thu, May 7, 2009 at 17:52, Marcel Offermans <[email protected]> wrote: > On May 7, 2009, at 17:17 , Guillaume Nodet wrote: > >> Right, we've already talked about that. But can Ace handle the simple >> use case I outlined? > > You mean this one: > >>> Take a simple example where you have a shell installed and you want to >>> deploy a new service along with its commands. The deployment admin >>> would not really allow to do that afaik. > >> > > If you provision a target (let's call it "A") with Ace, you usually start > out with an "empty framework" with just a management agent installed. Taking > that as a starting point, you first deploy the shell. That will trigger the > creation of the first version of a deployment package "A" for this target > with a version of 1. Later you decide to deploy that new service plus its > commands. That means an update of deployment package "A" is created, with a > version of 2. Fix packages (containing just the delta between version 1 and > 2) are also supported. > > Greetings, Marcel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
