continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marica Tan" <>
Subject Re: Multi-module builds in Continuum
Date Wed, 30 Apr 2008 08:01:28 GMT
On Fri, Apr 18, 2008 at 12:26 PM, Marica Tan <> wrote:

> Hi everyone,
> Current Scenario:
> When changes/updates occured in between builds of a multi-module project,
> some modules failed to build because of those changes not being reflected.
> Let say we have a scheduled build of a multi-module project with
> sub-project A, B and C, where C is dependent on A.
> B is currently building when changes was made on A and C. So when C gets
> to build it fails because changes on A wasn't reflected.
> Our group here in Exist had some discussions on how to approach this
> problem, which somehow also addresses
> So far we've came up with a list of things that we would like to propose.
> 1. This is the current scenario when building a multi-module project: for
> every module, the steps performed are checkout/update then build. What we're
> proposing is to checkout/update group atomically before builds, meaning
> there will only be one checkout/update and this would be at the group level.
> The build order is still like the current process (by dependency order), the
> only difference is that the checkout/update will be performed only once at
> the group level and at the start of the group build.
> 2. Notification will be moved at the end of the group build.
> 3. Reflect the changes in UI. Maybe a tree view.
> 4. Add features related to building

> 5. Aggregated build result/in progress

This is actually under number 4.  There will only be one build result per
group instead of having one per project.

> 6. Need skip/don't build state that retains previous state for statistics.
> 7. Cancel build is still per project. When a build is cancelled, it will
> trigger a skip.
>    - can set a flag that the build was cancelled / skipped, but the state
> is still the previous state.
> 8. Add group cancel
> 9. Add transient state

I'll create another thread for this.

> 10. Decision to build is still per project

This is just a note.

> 11. Track hierarchy in config

A project should be aware of its parent and its children or sub projects to
handle building of project group that has more than one pom with modules.

|    |__C
|    |__D

>From the figure above, after D finishes building, I could return to A and
build E.

> Comments, suggestions, violent reactions are welcome :)
> Thanks,
> Marica

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message