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 <[EMAIL PROTECTED]>
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
