On 15/09/2006, at 12:34 AM, Emmanuel Venisse wrote:
Personally, I prefer the PULL method.
Agreed.
I think we need to have two type of analysis.
The first is for dependencies that have a corresponding project in
continuum.
The second is for other dependencies that are available in the repo.
For the first one, we need the lastKnownBuildId or just check if
the latest dependy build is more recent than the latest project build.
For the second, we can check the timestampof the dependency or just
check if the dependency file is more recent than the latest project
build.
I think we need to check if the parent pom is newer or not too.
For PULL(3), I think too that it will be for 1.2 because it require
lot of work. Trygvis has started a branch with osworkflow but if I
remember it correctly, he didn't like it and want to try his own
engine started in plexus-sandbox/plexus-components/plexus-spe
Emmanuel
Kenney Westerhof a écrit :
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
