continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Edward Gruber <>
Subject Re: project group shortcuts
Date Sat, 04 Nov 2006 17:46:12 GMT
This sounds pretty good, but I want to make sure of something - the
groupId and projectId should obviously be editable, so you can have
alternate branches of the same groupId/artifactId maven combo within the
same continuum instance.  To that end, the project import should
probably have an option to specify at load time what hte groupId will be
for the group, to allow you to import the default first, then import
another later that shares the same real maven groupId.

To that end, also, I think that the projects should still have an
internal primary key that's integer based, but that (continuum)
groupId+projectId should be an alternate "business key" for the
integerId.  This, of course, to avoid craziness between multiple copies
of project groups.

Otherwise, I think this can make the whole thing quite a bit easier to
deal with.


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


*christian** gruber + process coach and architect*

*Israfil Consulting Services Corporation*

*email** + bus 905.640.1119 + mob 416.998.6023*

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message