Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: pass (herse.apache.org: domain of jesse.mcconnell@gmail.com
 designates 64.233.182.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=MXGh64RRSmlIws+w2DTURMQoFvHIiVkHYL4lUnvAM8xkdul9iCeI/Agq2TVYwQI4VJolINggzCFK4Ji3B06EI1GpjK+7Ll+aQN7Egi2qQ1BUaCxX7cloyBOIi56lQA4wC9wdDsJZKA/nUS0f6k0742ZoQTRpDmdSnjhCL4yXHBI=
Message-ID: <a43524d00611040824u5fac16e4ke466158527f55ae3@mail.gmail.com>
Date: Sat, 4 Nov 2006 10:24:28 -0600
From: "Jesse McConnell" <jesse.mcconnell@gmail.com>
To: continuum-dev@maven.apache.org
Subject: Re: project group shortcuts
In-Reply-To: <a43524d00610301406i62477879h253a08a2e26e4734@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <a43524d00610301406i62477879h253a08a2e26e4734@mail.gmail.com>

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 <jesse.mcconnell@gmail.com> 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
>
> http://ci.goo.org:9090/Doxia 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@gmail.com
>


-- 
jesse mcconnell
jesse.mcconnell@gmail.com