Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: pass (asf.osuosl.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=oyJ9kbcQKOu11Plb0mygbgsSFxVfj18hzhxv2spRj77F4eXSEwN54lQM9wcQwtnfUBeIZBPAt35ASv2D+ypUNqRBmIABoMH5CTEcogE90L5kNJQOi+QaGrEcCj+uBE4UexIG6ofmlFCnQxIMBnvuhXUPtzEM7g/AqjCqrd6Z8og=
Message-ID: <a43524d00610171816kcec5c21n3eeeef01e1192b89@mail.gmail.com>
Date: Tue, 17 Oct 2006 20:16:42 -0500
From: "Jesse McConnell" <jesse.mcconnell@gmail.com>
To: continuum-dev@maven.apache.org
Subject: Re: Proposed: UI for build defs (default build defs)
In-Reply-To: <4535729A.1060701@israfil.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4535729A.1060701@israfil.net>

well when I worked on this I added in some core.actions to do some of
this kinda logic

     * 1) project groups have default build definitions
     * 2) if project has default build definition, that overrides
project group definition
     * 3) changing parent default build definition does not effect
project if it has a default declared
     * 4) project groups must have a default build definition

that was from the javadocs on the
resolveDefaultBuildDefinitionsForProjectGroup method on
AbstractBuildDefinitionContinuumAction

jesse

On 10/17/06, Christian Edward Gruber <cgruber@israfil.net> wrote:
> Hey all,
>
>     I mentioned this on IRC and felt it should be sent ot the list.
> The notion of default build def is really wierd, now that groups are
> there.
>
>     In particular, can the "default build def" for a project be a group
> def, or only a project def.  The UI for this is also crapped out, as the
> check-box is dangerous.  If you "uncheck" a default project, who becomes
> defualt?
>
>     I think we need a drop down on a per-project basis, which MAY
> include both project and group builds as that project's default build
> def.  If you delete a build def, there would have to be logic to
> fail-into another build def, or the delete should be disallowed until
> you reassign all projects that hold it as a default.
>
>     Then if a user hits "build group" then (in build order) the default
> build def for each project is scheduled in turn.
>
> Christian.
>
> --
>
> *christian** gruber + process coach and architect*
>
> *Israfil Consulting Services Corporation*
>
> *email** cgruber@israfil.net + bus 905.640.1119 + mob 416.998.6023*
>
>
>


-- 
jesse mcconnell
jesse.mcconnell@gmail.com