Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: error (idunn.apache.osuosl.org: domain apache.org from
 131.174.93.58 cause and error)
Date: Thu, 14 Sep 2006 14:53:05 +0200
From: Kenney Westerhof <kenney@apache.org>
Subject: Dependency triggered builds
To: continuum-dev@maven.apache.org
Message-id: <450950B1.900@apache.org>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=UTF-8
Content-transfer-encoding: 7bit
User-Agent: Thunderbird 1.5.0.5 (X11/20060812)


Sending again, it doesn't seem to have made the list.

-------- Original Message --------
Subject: Dependency triggered builds
Date: Thu, 14 Sep 2006 10:30:01 +0200
From: Kenney Westerhof <kenney@apache.org>
To: continuum-dev@maven.apache.org

Hi,

I wanted to propose some solutions for triggering builds if dependencies are changed.

(I mean: if project A depends on project B, and project B was updated/rebuilt, then
A should also be rebuilt to check for any api breaking changes etc.).

>From the top of my head I can name 2 distinct approaches: push and pull.

PUSH: When project B was succesfully built (no need to trigger other builds for broken
 builds - no new artifact is available),
 Continuum will schedule forced builds for all projects that depend on the current project.

PULL (1): MavenTwoContinuumProjectBuilder does an SCM check to see if there are any source changes.
 Add another check here to see if any dependencies have newer build Id's. This requires a 'lastKnownBuildId'
 field to be added to the project<->project relation (Dependency).

PULL (2): 
 Same thing, except we just check for the timestamp of dependency builds. If they're newer than ours,
 then run the build.

PULL (3):
 Either one of the above, but not in the project builder, but as a task-entry-evaluator.
 Also the 'SCM' up2date check would be moved to an evaluator class (something like if ( `svn log CURRENT:HEAD | wc -l` > 0 ) {}: don't update
 the checkout, just check if it would be changed).

 If the first evaluator fails, the next one isn't called (I assume...). This is an 'AND' operation.
 We might also want to support an OR operation, (scmChanged || depsChanged).

 This is starting to look like a workflow. The advantage of this is that we can break down all the operations
 that are now hardcoded in the different build executors to separate actions that we can chain together,
 and add decision points. 

 We could use Werkflow/OSWorkflow or some other engine, or just plexus, which already has a workflow engine (in the form of the taskQueue).
 For instance (without TaskEntryEvaluators):

	Each action defines it's outputs: yes/no/others as requirements.

 	The first action would be 'CheckDependenciesChangedAction'.
	If this evaluates to 'yes', it schedules the 'yes' action, which would
	be the BuildProjectTask.
	When 'no', then schedule 'CheckSCMUpdatedAction'.
	
	and so on and so forth.
 
With TaskEntryEvaluators this could also be done, as long as each evaluator can specify the next evaluator to run.

But I think this is for 1.2; just wanted to bring it up for discussion.

If there's no feedback on a preferred solution I'll go with either the PUSH or PULL 1/2 solutions,
whichever is easiest. I'll do some research on what's there yet to support this.

-- Kenney