continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marica Tan" <c...@exist.com>
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 <ctan@exist.com> 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
> http://jira.codehaus.org/browse/CONTINUUM-798.
> 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.

A
|__B
|    |__C
|    |__D
|__E

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


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

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