Some more input on steps 7 and 9.
I agree with your other comments (snipped out to keep this short).
Raymond Feng wrote:
[snip]
7. Upload cloud.jar, find deployable composite http://cloud#cloud in
it, mark it deployed. The red-x on deployed composite
http://store#store is now gone.
We should be able to deploy multiple composites in one shot as they
might have cross-references.
Yes, but the simple "one composite at a time" deployment scheme that I
described still supports your cross-reference case, or am I missing
something?
Or the GUI could select the required
contributions/composites as we mark one deployable composite.
We could do that, except that the required composites might not be
available in the domain yet.
[snip]
9. Select http://cloud#cloud and associate it with machine2. Cloud.jar
and assets.jar are downloaded to machine2 and machine2 is configured
with http://cloud#cloud.
Who initiates the download? Is it a pull or push model?
I was thinking about push: the domain triggers the download.
To avoid over-engineering this too quickly, how about starting simple
and just generating a zip of the artifacts and let the administrator FTP
and unzip it on the target machine?
In other words I think we need to be comfortable with executing the
install / resolve / deploy / configure / distribute steps manually
before trying to automate them.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
