continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Thakur <>
Subject Re: project group shortcuts
Date Mon, 06 Nov 2006 04:22:00 GMT

Yep, this would be a nice improvement to look forward to from a 
usability perspective!

While I can imagine generating suggestions for GroupId values for new M1 
and M2 projects being added, I am not sure how we could come up with 
something similar for Shell or Ant projects.


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

View raw message