The original proposal was web services based, but the entire
process occurring from Continuum is definitely useful. I think the
concrete drivers are:
Right, so like other stuff there is a backend service, and it is
exposed in the same way to both a web interface and an xmlrpc client,
but neither depend on the other?
1) release:prepare from the CLI with the release plugin and pushing
a release descriptor to Continuum. Then using the Continuum Web UI
to perform the release.
2) talking to continuum via web services from an IDE to do the
release:prepare. Then using the Continuum Web UI to perform the
release.
3) talking to continuum via web services from an IDE to do both the
release:prepare and release:perform.
4) the case noted above
The the WEB UI needs to cleanly account for the separation so that
the perform is not tied to the preparation being done in the web ui.
yes, good idea.
- flesh out the release descriptor which is used for a release
yep, that's what I was referring to when I mention "model".
- flesh out the release manager component and it can just delegate
to the release plugin i suppose though separating a release manager
component as has been discussed with Jeremy I think would be a good
thing to do.
Is this the one in continuum that handles the backend of this
service, or are you referring to pulling all the code out of the
release plugin?
For a multi module build when would you not use the parent? If you
wanted a specific component that could be recorded in the release
descriptor.
I think you'd always want the parent, but since we have no notion of
the association in Continuum I'm just wondering how it gets handled.
A release build is different then what Continuum is typically doing
so some separation I think would be wise so that in the UI release
specific builds could be identified so possibly a separate queue
with some different parameters so that release builds can't be
interfered with.
I'm not sure what you mean here, we generally need builds to be
separate and not interfered with (for example, when we start building
on two different JDKs on the same instance we'll want to make sure
they don't conflict - I view that as the same thing)
I think we should think about this now instead of hacking out
something. Jeremy and Edwin seem to have some time so let's address
all the points outlined above. Have some feedback on design, which
shouldn't take long, and then implement.
+1 to design first.
I'm not sure we need to worry about build queues in this iteration,
though. That could get right down into the continuum internals.
Anyway, I'll leave that up to Edwin and Jeremy.
I think as long as all the design, which I'm sure both Jeremy and
Edwin will contribute to, is out on the table and we all agree then
they can work out the implementation. I think as they are both
relatively new contributors this is the best course forward.
+1
- Brett
