Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <4551D196.3070801@venisse.net>
References: <a43524d00611071451y35fc2621hcb310156bc8d99db@mail.gmail.com>
	 <4348D4E5-F8E8-49D6-9039-35A84C31F67F@apache.org>
	 <4551A002.1080305@venisse.net>
 <a43524d00611080356v13b64d03jfe5293509b31ea1d@mail.gmail.com>
 <4551D196.3070801@venisse.net>
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <AFABE42C-8E0A-45D9-97EF-327112EF1246@apache.org>
Content-Transfer-Encoding: quoted-printable
From: Brett Porter <brett@apache.org>
Subject: Re: build scheduling issues
Date: Wed, 8 Nov 2006 23:52:41 +1100
To: continuum-dev@maven.apache.org

Sorry, am I missing something? How do we end up with a cycle in =20
Continuum? Is there a specific example?

I know it's possible - we had to allow it in the repository (eg, =20
dom4j <-> jaxen), but it is certainly undesirable and honestly should =20=

be rare, especially in m2 built artifacts. Should it produce a build =20
warning?

Basically, the treatment there is to just stop following the tree =20
when you hit the cycle, rather than changing the way things are =20
ordered. So it's really arbitrary which might come first, but isn't =20
really a concern there.

Anyway, just wondering.

Cheers,
Brett

On 08/11/2006, at 11:46 PM, Emmanuel Venisse wrote:

> Yes
>
> Jesse McConnell a =E9crit :
>> we should add a page that analyzes each schedule for cycles...that
>> would be a cool little feature
>> On 11/8/06, Emmanuel Venisse <emmanuel@venisse.net> wrote:
>>> Yes, we need a global ordering, so projects will be build =20
>>> independently of groups, because in some
>>> case a cycle can be created between groups (not necessary between =20=

>>> projects).
>>>
>>> In case a cycle is detected between projects, continuum can't =20
>>> find the build order. In this case, I
>>> think we need to sort a little project so will reduce build =20
>>> errors. So if we have a cycle, we can
>>> sort projects in a group and build them. In most of case (maven =20
>>> projects), we don't have a cycle in
>>> a group.
>>>
>>> Emmanuel
>>>
>>> Brett Porter a =E9crit :
>>> > I think you want global ordering. Grouping should just be a
>>> > display/management technique, not anything that changes how =20
>>> projects are
>>> > handled.
>>> >
>>> > However, this needs to be reviewed as a whole (which I think =20
>>> Emmanuel is
>>> > doing), such that builds can be triggered when their =20
>>> dependencies change
>>> > which will help with the ordering as it won't be dependant on =20
>>> 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=20
>>> ( Schedule id
>>> >> ) method and after discussing some things with Emmanuel...I =20
>>> think we
>>> >> have a problem here.  When I went through and refactored =20
>>> things to
>>> >> support a more Project Group centric setup with continuum I =20
>>> changed
>>> >> this method a bit.
>>> >>
>>> >> Originally, this method would gather up all projects that =20
>>> would be
>>> >> triggered by that schedule, run them all through the project =20
>>> sorter
>>> >> and then build each in sequence.
>>> >>
>>> >> When I added the project groups to this mix, I changed things =20
>>> to be on
>>> >> a project group basis, so that on a project group by project =20
>>> 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, =20=

>>> sort them
>>> >> 17:15 <evenisse> if we don't have a cycle, it's ok and we =20
>>> 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 =20
>>> group...the
>>> >> way it currently is (with my change) it would process all =20
>>> triggered
>>> >> builds within one group and then process all triggered builds =20
>>> in the
>>> >> other group.   This would not take into account potential =20
>>> dependencies
>>> >> between the two.
>>> >>
>>> >> Does anyone have any thoughts on this?  I am inclined to fix =20
>>> it up so
>>> >> its like it used to be where all projects across all project =20
>>> 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 =20
>>> the third
>>> >> comment there.  In our conversation on this he said that he =20
>>> thinks
>>> >> that the cycles are cropping up all the time, and if thats the =20=

>>> case
>>> >> then we are building a lot of unordered builds which would =20
>>> account for
>>> >> some of the strange reports we have been getting.  Are you =20
>>> saying that
>>> >> if we detect the cycle we default back to the way I am doing =20
>>> it now?
>>> >> order within the groups...
>>> >>
>>> >> jesse
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --jesse mcconnell
>>> >> jesse.mcconnell@gmail.com
>>> >
>>> >
>>> >
>>>
>>>