continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: short term branch for project/group keys
Date Fri, 22 Dec 2006 21:11:55 GMT

On 23/12/2006, at 12:24 AM, Jesse McConnell wrote:

> 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.

Ok, so a project(Group)? will have:
id : int
key : String
name : String
...

Where key is used as a reference, id is used as a datastore/model  
identity, and name is used as a display. Sounds good.

We could then have a table of "old names":
id : int
oldKey : String

These could be used so that failed lookup on a key could then look in  
the old key's to find out what the new one is (like when you move an  
issue in JIRA). I'm not sure this is needed initially - only if we  
support picking up renames to the project itself.

I suggest that a project should, by default, use the Maven group ID  
and artifact Id as the group key and project key respectively.  
Obviously, for Ant/Shell/etc, this will need to be entered by hand.

> 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

Cool. We could also do nice things with the URLs using a WW mapper:

/continuum/org.apache.maven/maven-project/buildHistory

>
> 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

For now sounds good (would like to review immutability later), though  
suggest using Maven IDs where possible.

>
> 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.

Sounds good. I'm not sure how often you really need to reference a  
schedule or build definition (or how you'd really appropriately  
describe them). We don't want to go to the point where you have to  
make up extra information that is not useful.

>
> 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.

Whoa. Repeat the mantra - convention over configuration :)

One of the great strengths of Continuum is that it takes its defaults  
from Maven. Sure, they can be changeable, but they *must* be the  
default. That's not a mess.

As for multiple branches - I'm not convinced either way yet. I Can  
see the merits in your example of simply making them new projects,  
but then they need to be reconfigured (often in the same way). On the  
other hand, it could be that branches should be a subsection of the  
project, not an additional project. The hierachy would be group >  
project > branch/instance. Notifiers and build definitions would be  
attached to the group or the project, and can be excluded from a  
given branch/instance if not used there.

Let's discuss that separately as it's obviously new functionality,  
whereas loading them up as new projects is a workable current  
solution. If we take the defaults, all that means is that adding a  
second one should complain, and you need to edit the key. No big deal.

- Brett



Mime
View raw message