Return-Path: 
 <continuum-dev-return-5379-apmail-maven-continuum-dev-archive=maven.apache.org@maven.apache.org>
Delivered-To: apmail-maven-continuum-dev-archive@www.apache.org
Received: (qmail 32477 invoked from network); 8 Nov 2006 01:54:24 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 8 Nov 2006 01:54:24 -0000
Received: (qmail 90594 invoked by uid 500); 8 Nov 2006 01:54:35 -0000
Delivered-To: apmail-maven-continuum-dev-archive@maven.apache.org
Received: (qmail 90572 invoked by uid 500); 8 Nov 2006 01:54:35 -0000
Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:continuum-dev-help@maven.apache.org>
List-Unsubscribe: <mailto:continuum-dev-unsubscribe@maven.apache.org>
List-Post: <mailto:continuum-dev@maven.apache.org>
List-Id: <continuum-dev.maven.apache.org>
Reply-To: continuum-dev@maven.apache.org
Delivered-To: mailing list continuum-dev@maven.apache.org
Received: (qmail 90561 invoked by uid 99); 8 Nov 2006 01:54:35 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Nov 2006 17:54:35 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [203.59.1.145] (HELO
 customer-domains.icp-qv1-irony10.iinet.net.au) (203.59.1.145)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Nov 2006 17:54:19 -0800
Received: from 203-158-38-82.dyn.iinet.net.au (HELO [192.168.237.86])
 ([203.158.38.82])
  by customer-domains.icp-qv1-irony10.iinet.net.au with ESMTP;
 08 Nov 2006 09:53:38 +0800
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAAJnHUEXLniZSdGdsb2JhbAANjD0B
X-IronPort-AV: i="4.09,398,1157299200";
   d="scan'208"; a="23948754:sNHT5568809346"
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <a43524d00611071451y35fc2621hcb310156bc8d99db@mail.gmail.com>
References: <a43524d00611071451y35fc2621hcb310156bc8d99db@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4348D4E5-F8E8-49D6-9039-35A84C31F67F@apache.org>
Content-Transfer-Encoding: 7bit
From: Brett Porter <brett@apache.org>
Subject: Re: build scheduling issues
Date: Wed, 8 Nov 2006 12:53:35 +1100
To: continuum-dev@maven.apache.org
X-Mailer: Apple Mail (2.752.3)
X-Virus-Checked: Checked by ClamAV on apache.org

I think you want global ordering. Grouping should just be a display/ 
management technique, not anything that changes how projects are  
handled.

However, this needs to be reviewed as a whole (which I think Emmanuel  
is doing), such that builds can be triggered when their dependencies  
change which will help with the ordering as it won't be dependant on  
them all being triggered at the same time?

- Brett

On 08/11/2006, at 9:51 AM, Jesse McConnell wrote:

> I was reading through the DefaultContinuum.buildProjects( Schedule id
> ) method and after discussing some things with Emmanuel...I think we
> have a problem here.  When I went through and refactored things to
> support a more Project Group centric setup with continuum I changed
> this method a bit.
>
> Originally, this method would gather up all projects that would be
> triggered by that schedule, run them all through the project sorter
> and then build each in sequence.
>
> When I added the project groups to this mix, I changed things to be on
> a project group basis, so that on a project group by project group
> basis it would order the projects and build them.  At the time I
> thought this was the way to go...but maybe not.
>
> 17:14 <evenisse> we need to take all projects from all groups, sort  
> them
> 17:15 <evenisse> if we don't have a cycle, it's ok and we build all
> 17:15 <evenisse> if it isn't ok, we sort project by group
>
> For example, if we loaded up a Plexus group and a Maven group...the
> way it currently is (with my change) it would process all triggered
> builds within one group and then process all triggered builds in the
> other group.   This would not take into account potential dependencies
> between the two.
>
> Does anyone have any thoughts on this?  I am inclined to fix it up so
> its like it used to be where all projects across all project groups
> are thrown into the graph....I keep feeling like I am missing
> something wrong with this, but I can't pin it down.
>
> One thing that perhaps Emmanuel could explain a bit more is the third
> comment there.  In our conversation on this he said that he thinks
> that the cycles are cropping up all the time, and if thats the case
> then we are building a lot of unordered builds which would account for
> some of the strange reports we have been getting.  Are you saying that
> if we detect the cycle we default back to the way I am doing it now?
> order within the groups...
>
> jesse
>
>
>
>
>
> -- 
> jesse mcconnell
> jesse.mcconnell@gmail.com