question for anyone listening regarding project grouping and things like notifiers and build definitions.
I am working through making a project group utility class for hiding some of this kinda logic from the webapp actions and ran across a little issue in terms of the model. Using build definitions as an example, each build definition uses an integer id that is the only test for equality in a .equals(object) test. Now when I am running through all of the projects in a project group I would like to aggregate these guys together based on equality in all fields other then the id because at the project group lvl they should present as equal if their arguments and schedules are identical. Conversely when I am applying a build definition back to each of the projects I would like to maintain that same build definition across different projects. This basically results in a slightly different model being returned after aggregating and modifying equivalent build definitions. 1) does anyone see this as a problem in handling it this way? I could proxy the equivalent build defintions somehow and maintain their original build id's but that just seems silly to me given my current understanding 2) would I be better off adding the ability to set build definitions and notifiers to the ProjectGroup in the model and dealing with things that way? I think it is important to maintain this kinda individual notifiers and build defintions on the project level for one off hacks and special needs, but I see the natural evolution of project groups in continuum making it much easier to influence those kinda things (build definitions and notifiers) at the project lvl and having them inherited by project members... thoughts? answers? slap downs? :) jesse On 8/3/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:
on the security thread there was some dicussion of project grouping, which is also on the continuum roadmap for 1.1 and in jira under a number of issues, CONTIUUM-30 being one of the original ones.. I have been taking a stab at this locally and wanted to see if I could get some feedback for this before I start submitting patchs for it. My general idea is partially on the white-site that brett commited last week but this is the general idea. The front page for continuum right now is the summary.jsp page which lists out all of the projects in continuum. These are internally structured into project groups which only appear on that summary page as a column giving the name of the project group. What I have done so far is create a groupSummary.jsp and associated view model and action that allows the front page to render out each project group and the projects inside of it, the projects render with a bit less of the information then the straight summary page, but the title for each table of projects is clickable taking you to the old summary.jsp page which has been pared down to contain just the projects in a particular project group. So basically you have the front page able to render out all projects broken out into seperate tables based on project group. my intention now is to make project group configuration pages that let you initially setup notifiers and whatnot at the top lvl that would be replicated through all of the child projects, this should make project group management easier as right now you have to go through each project one by one to configure those things. The singular project management would remain the same, only it would allow you to tweak the items setup by the top lvl project group management screens. I'll try and go through and align the white-site with this as well but I also want to get it themed right with the current look and feel (and bretts new new look and feel he commented about on another thread) oh, and once this kinda functionality is in place then it should be pretty easy to make a project group lvl setting for things like 'build on dependency changes' thoughts? jesse -- jesse mcconnell [EMAIL PROTECTED]
-- jesse mcconnell [EMAIL PROTECTED]
