continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Venisse <emmanuel.veni...@gmail.com>
Subject Re: separating the builder code from the UI
Date Thu, 25 Jun 2009 15:20:51 GMT
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 <wsmoak@gmail.com> 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<brett@apache.org> 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
> > brett@apache.org
> > http://blogs.exist.com/bporter/
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message