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" <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED]
