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,
save
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:
project.addBuildDefintion(updatedBuildDefintion);
store.saveProject(project);

and,

group.addBuildDefinition(updatedBuildDefinition);
store.saveProjectGroup(group);


2)  Another thing that Jesse mentioned in his email about breaking up
Continuum
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,
possibly

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 :-)

Thoughts?

Cheers,
Rahul


----- Original Message ----- 
From: "Jesse McConnell" <jesse.mcconnell@gmail.com>
To: <continuum-dev@maven.apache.org>
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
> jesse.mcconnell@gmail.com