continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <jesse.mcconn...@gmail.com>
Subject Re: continuum project groups
Date Mon, 07 Aug 2006 20:40:43 GMT
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 <jesse.mcconnell@gmail.com> 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
> jesse.mcconnell@gmail.com
>


-- 
jesse mcconnell
jesse.mcconnell@gmail.com

Mime
View raw message