continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <jesse.mcconn...@gmail.com>
Subject Re: short term branch for project/group keys
Date Tue, 26 Dec 2006 21:28:41 GMT
rahul and I have been talking on skype some working out some of the
details of this key refactor and we see an opportunity to do a few
things that might make life better for continuum.

He is going to mail soon on some things that we are wanting to do in
the store and this mail is one something to do with the
DefaultContinuum object itself.

I am thinking of breaking up the Continuum interface into two objects
(perhaps three) interfaces that have more targeted purposes.  Looking
through the Continuum interface right now it has largely three
purposes.

1) top lvl actions (getting all projects, building all projects,
firing off adding of groups based on metadata, etc)

2) group actions (adding notifiers to groups, build definitions, etc)

3) project actions (adding notifiers to projects, build definitions, etc)

In many methods for 2 and 3 the continuum instance is just acting as a
facade over the store api doing lots of pass through function calls.
Some places in continuum project shun the use of the Continuum
interface for these things and just use the store api directly having
plexus inject the ContinuumStore instance into the components.

If you look at the Continuum interface as it stands right now there
are a number methods like

addBuildDefinition <- deprecated
addBuildDefinitionToProject
addBuildDefintionToGroup

Rahul is going to mail on how this can be cleaned up in the store api,
but I question why we want these methods on the Continuum interface at
all?

My thought at the moment is to take methods like
'getBuildDefinitionForGroup' and move those to an interface for group
related actions that can't be directly on the ProjectGroup model
class.  Then perhaps do the same for the
'getBuildDefinitionForProject' type methods.  This would solidify the
focus of the Continuum interface to be a lookup for particular project
group's and project's as well as top lvl continuum functionalities
like building all projects using the ProjectSorter, etc.

The we would have a ContinuumGroup and ContinuumProject interface and
impl that could act as facade's over the model classes and some of the
other logic oriented methods that are currently in the Continuum
interface.

thoughts?  rahul and I are pretty happy with the way it sounds atm

jesse

--
jesse mcconnell
jesse.mcconnell@gmail.com

Mime
View raw message