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 66.249.82.239 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=FPW4/ylqkt/lxkC7tm8VVtzcLMfM6y2iHzybHeoHlEMeSlteIuCLvLdkiZ4gXWgFQwhMV3SncaJw9uzCE1KiMCe0Gx86EgtAXHohmMEPtqIGhzDvctTMXk04qw5jud8c1xNqXvW+FjCGKG6p01U/zv6KPMIqMmVQZJ1XjzL7sfs=
Message-ID: <a43524d00612220524w15e94c86md20d6740c0431cf4@mail.gmail.com>
Date: Fri, 22 Dec 2006 11:24:56 -0200
From: "Jesse McConnell" <jesse.mcconnell@gmail.com>
To: continuum-dev@maven.apache.org
Subject: Re: short term branch for project/group keys
In-Reply-To: <36FDE11F-5D15-4158-927A-36550539B00C@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <a43524d00612211130q64d98545v349e20547d865e73@mail.gmail.com>
	 <36FDE11F-5D15-4158-927A-36550539B00C@apache.org>

On 12/22/06, Brett Porter <brett@apache.org> wrote:
> Sounds good, as long as the store remains independent of them. I
> don't want to get into the situation like in JIRA where you can't
> rename a string key.

Yes, jason pinged me on this since I guess I wasn't completely clear
in that summary.

the project.id and projectGroup.id will basically disappear from
continuum, reserved strictly for the underlying store.  The store can
do whatever it wants with them.  The UI will never pass around a
projectId=26 param on a url making you wonder what the heck it was.  A
nice side effect of this IMO is that the #'s in the working directory
would go away as well, defaulting instead to a nested directory
structure of workingDirectory/GroupKey/ProjectKey/pom.xml

Now I had honestly been thinking of making the key's immutable, since
the names of the group's and project's are to be used for all
presentational type things.  I was going to treat keys under the same
functional requirements that usernames generally have.  Maybe we offer
a 'Clone' option that makes a deep copy of the data in the DB into a
new name and then allow the deletion of the old one...

Anyway, here are the restrictions I thought of placing on the keys.

* [a-zA-Z1-9.-:] for all keys
* group key is unique
* group key + project key is unique
* project key should _not_ need to be unique  (ex Doxia/Core +
Maven/Core + Continuum/Core)
* keys are immutable, set upon creation

> Before starting to hack on this, perhaps you could list out all the
> keys you think are needed, and some examples? I'm interested in how
> it relates to group IDs and artifact IDs in particular.

Initially I was planning on doing just the project key and group key
since there is so much involved with getting just those two in place.
However everything would probably go that way so that Profiles,
Schedules, BuildDefinitions, etc...anything with an int ID that is
used around in continuum would be converted to use a strongly typed
string key instead....the ones other then project and group are less
important in the short term since they are not a constant source of
confusion...but eventually yes anything with and ID would get a Key
like this.  If the branch is a success and is voted back onto trunk
then those could take place on trunk I think since they are smaller
scope.

As for how they would relate to groupId's and artifactId's it was not
my intent to deal with those at all.  One of the things that got us
into the mess that currently exists was too great a focus on the m2
side of continuum.  IMO the group and project keys should be kept
external to any concept of project type.  That way we can always
maintain a clear delineation between a group and its member projects
in relation to other groups.  For instance, one of my goals here is to
make it super easy to have multiple versions of Doxia load up in
continuum and execute in their little sandboxes.
Group Keys of Doxia and Doxia-Refactor (just an example branch) should
be able to seamlessly import the doxia project from its relative
sources and peacefully coexist.  And it should be just as easy to do
the same with a number of ant, shell and maven1 projects.

Anyway, some foreseeable real world example keys in one continuum instance:

Group:
  Maven-Trunk
Projects:
  Core
  Api
  Artfiact

Group:
  Maven-2.0.5
Projects:
  Core
  Api
  Artifact

Group:
  Continuum
Projects:
  Core
  Api
  Store
  Webapp

cheers,

jesse


> - Brett
>
> On 22/12/2006, at 6:30 AM, Jesse McConnell wrote:
>
> > I am thinking about pulling a short term branch of continuum with
> > rahul and working on getting everything converted to using a string
> > based key project and project group reference in all apis and in all
> > of the UI decision making items.  He has tomorrow off so I think that
> > unless anyone has any big issues with it we'll try and make that
> > branch and work on it tomorrow.
> >
> > the end result of it would be:
> >
> > * int id's for project and project group in the model are for internal
> > store usage
> > * name's for project and project group are for presentation
> > purposes only
> > * key's are for all api usage and passing around un URL's etc.
> >
> > some quick benefits are:
> >
> > * consistency across all apis and url manipulations
> > * ability to add quick url rewriting for direct linking of projects
> > foo.org/Doxia/Core
> > * common keys across running continuum instances for clustering
> >
> > jesse
> >
> > --
> > jesse mcconnell
> > jesse.mcconnell@gmail.com
>


-- 
jesse mcconnell
jesse.mcconnell@gmail.com