I'd prefer to decide what will be Continuum 2.0. I won't like to start to work on a new architecture if we aren't sure because we'll spend lot of time to write a POC, so personnaly, I'd prefer to start directly in trunk.
Emmanuel On Thu, Jun 25, 2009 at 4:57 PM, Wendy Smoak <[email protected]> wrote: > I think Emmanuel just beat me to raising the topic of getting > (re-)started on this. :) > > The diagrams from Brett's mail are here: > http://continuum.apache.org/ref/1.4.0-SNAPSHOT/architecture.html > (and the source files are available if anyone wants to edit, but they > are in OmniGraffle right now, which is not free.) > > Rather than deciding up front that this will be Continuum 2.0, how > about a code-named branch? > > -- > Wendy > > On Thu, Apr 10, 2008 at 11:48 PM, Brett Porter<[email protected]> wrote: > > Hi, > > > > I've been thinking ahead a bit about a potential design change I'd like > to > > make. At the moment, at a very coarse level, we have the "Core" which > does > > just about everything :), which is comprised of a few modules, and the > > webapp/xmlrpc sitting on top of that. It looks something like [1]. It is > > pretty well separated from the UI, but the parts of the core are not well > > separated and hard to test, and the store/model is pervasive through > > everything. > > > > I would like to propose factoring out the bit that does the building, > > something like [2]. > > > > This is not a totally radical change, though it will change the workflow > a > > bit such that: > > * the builder has no database interactions. So it will be on the return > > events that contain results that get persisted in the database > > * notification will be based on the return events, not part of the build > > logic > > > > Clearly demarcating where the database is used is a Good Thing I feel, > and > > it then becomes a way to store and visualise results. > > > > There are a couple of potential things that will later be possible with > this > > architecture: > > - the requests could be made over REST and the events sent back over a > JMS Q > > similar to GBuild - allowing us to move the builder to an entirely > different > > server, and to have multiple builders. If each has a given set of > > installations/environment profiles we can then aggregate results for > > different platforms > > - you could run Continuum with just the bottom layer for a really > simplified > > system. The only change we'd make here is that you'd hook up the > notifiers > > and other event responses directly instead of the Q > > > > I'd like to attempt this on a branch, making the minimal amount of change > > possible to see how it works. What do others think about this approach? > > > > Cheers, > > Brett > > > > [1] > > http://people.apache.org/~brett/continuum-proposal/continuum-now.png<http://people.apache.org/%7Ebrett/continuum-proposal/continuum-now.png> > > [2] > > http://people.apache.org/~brett/continuum-proposal/continuum-new.png<http://people.apache.org/%7Ebrett/continuum-proposal/continuum-new.png> > > > > -- > > Brett Porter > > [email protected] > > http://blogs.exist.com/bporter/ > > > > >
