continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Thakur" <>
Subject Re: short term branch for project/group keys
Date Wed, 27 Dec 2006 08:10:29 GMT
Store updates:
I am taking a stab at refactoring the current ContinuumStore into
RefactoredContinuumStore as a p-o-c for a couple of things.

1) Idea basically is that the Store interface should provide (lookup,
and delete) operations on key 'application' entities. I gather these are

o   Project
o   ProjectGroup
o   Schedule
o   Profile
o   Installation
o   SystemConfiguration

Updates to any children hanging off  key entities should cascade.
So, something like:

> addBuildDefinitionToProject
> addBuildDefintionToGroup

could be done like:



2)  Another thing that Jesse mentioned in his email about breaking up
interface into two or three - I am thinking perhaps it might be an idea
to break up the ContinuumStore into as many as well and have one-to-one
mapping between store and corresponding continuum interfaces. So,

o    ProjectStore (all project related operations)
o    GroupStore (all group related operations)
o    SystemStore (all top level operations - fetch all projects, groups.
Operations on Schedules, profiles etc)

The names above are just indicative, we can change them later :-)



----- Original Message ----- 
From: "Jesse McConnell" <>
To: <>
Sent: Wednesday, December 27, 2006 10:28 AM
Subject: Re: short term branch for project/group keys

> 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

View raw message