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]
