continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <>
Subject Re: project group shortcuts
Date Sat, 04 Nov 2006 16:37:57 GMT
oh, and perhaps I ought to do this on a quick branch for the duration of it...


On 11/4/06, Jesse McConnell <> wrote:
> Ok, I am going to try this out I think, here is a laundry list of what
> would happen followed by the benefits.
> * the id on project group and project classes usage is deprecated and
> goes back to being internal to the store, nothing references to a
> project or a group by 0,1,2,3 etc anymore.
> * groupId on the project group class becomes the unique string by
> which you access a project group, it is currently kinda floating
> around usage wise as sometimes the groupId from the pom loaded up on
> m2 projects
> * projectId is added to Project and is the unique string by which you
> refer to a project in a project group
> * groupId and projectId would be restricted to [a-zA-Z0-9.-] with no
> spaces and are the short names to refer to these group and project
> objects on the UI layer and everywhere else in continuum
> * cascading effects throughout a large chunk of continuum as the
> integer projectId and the freeform strings for projectGroupName and
> integer projectGroupId are deprecated and converted to the short
> names.
> benefits:
> * UI layer will standardize on how to refer to project groups and
> projects in those groups, without passing around internal jdo store
> identifiers, free form text strings or even the combination of both of
> those in some cases (this is a failing of mine from the project group
> refactor I did, it made the UI work clunkier in referring to these
> things)
> * by treating m1/ant/shell/m2 projects the same in the UI it should
> alleviate a ton of oddball UI issues that are cropping up where groups
> are created, not created, not referred to correctly, names not being
> passed around between linked actions, etc
> * following a convention for naming your groups and projects across
> instances of continuum will make clustering a lot easier, group 7 on
> this instance isn't necessarily group 7 in that instance
> * specifying the string group Id that you will refer to that group by
> on the adding of the project will allow you to load up multiple
> instances of the same project (ex one instance on trunk and one on a
> branch) into the same instance of continuum (versions in the poms for
> m2 should lets these play together nicely), right now I think the
> projects from that second addition will just add into the same project
> group unless you rename the name in the pom you are loading
> * the unique string project Id can be the same for the same project
> across multiple usages of that project in different groups, letting
> you refer to them as [Doxia/DoxiaCore] and [Doxia1.2/DoxiaCore]
> * m1/shell/m2/ant project groups are referred to in the exact same
> way, and get their values from the same source, on the adding of the
> group and underlying projects
> * we can have a GroupNamingMapper and ProjectNamingMapper interface
> that can be configurable to be used in the automatic generation of the
> string groupId and projectId so this naming process can be automated
> by following a convention in the naming of the poms for m2
> * the groupId and projectId string values can be edited at any time,
> letting the user load up the Doxia group and then later change it to
> the DoxiaTrunk group and then add in a DoxiaBranchFoo group
> I am sure there are other benefits, but these are the ones that keep
> pointing me in this direction.  I just think that we really need to
> take a step like this to clean up a lot of messy interactions between
> the UI layer and continuum core and the confusing mishmash of webwork
> action linkages involving groups and projects.
> anyone have any thoughts on this?  I am pretty sure I can have this
> all done in a couple of days of work and I really think it will help
> maintenance and future development.
> jesse
> On 10/30/06, Jesse McConnell <> wrote:
> >
> > last week I mentioned this in rahul's zero-conf mail
> >
> > > if this is really what we want to change here then perhaps we ought to
> > > make it an option for configuration of the project group in all cases,
> > > the ability to specify the name of the project group...or give it some
> > > kinda short identification element.  I kinda like that idea, then we
> > > can use 'Doxia' for 'The Doxia Project' and we can even use the short
> > > user input project group Id in the urls...
> > >
> >
> > to do this I would put a textfield on the project group creation screens and
> > then an edittable one in the project config screens, and add it to the
> > model.  This shortcut would replace the locations where the projectGroupName
> > is currently being passed around on actions to let projects know what group
> > is being interacted with.  Api changes obviously to support this as well,
> > but I don't think this would be too terribly bad to get into place. We get
> > to avoid passing around the jdo projectGroupId values which might get screwy
> > with clustering if we have different stores and the project groups are not
> > in sync.
> >
> > We would also be able to do some mapping to allow for direct url friendly
> > linking to the summary pages
> >
> > which would go to the groupSummary page for the
> > Doxia project.
> >
> > Does anyone have any objections to adding this functionality?  It would
> > clean up the interactions for the webwork actions dealing with project names
> > (having "The Doxia Project" passed around on the url's is kinda chintz) not
> > to mention allow the m1/m2/ant/shell project groups have a consistent way to
> > referring to the project group concept.  I can see a lot of bonuses and no
> > downsides right now...I think it will clean up a lot of different
> > interactions.
> >
> > jesse
> >
> > --
> > jesse mcconnell
> >
> >
> --
> jesse mcconnell

jesse mcconnell

View raw message