Continuum

Unrelated but inter-dependent projects in the same group are not built in the correct order

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.3.2 (Beta)
  • Fix Version/s: 1.3.3 (Beta)
  • Component/s: None
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

To reproduce, add three unrelated projects to a project group where one project depends on the other two, such as an EAR that depends on two WARs. They can use a master pom as <parent> but should not be part of a parent-with-modules hierarchy.

The expected behavior is for Continuum to build the WARs first and then the EAR, however this is not what happens in my example. The EAR is built first, causing it to have the wrong/old WARs inside and wasting time spent testing the wrong artifacts.

This happens whether or not multiple parallel build queues are used. With multiple queues, Continuum scatters the projects among queues and the build order depends on what finishes first. When restricted to a single queue, you can see the incorrect order as it moves through the queue.

Continuum should consider dependencies when ordering projects within a group, even if the projects are not part of a multi-module hierarchy.

[Unconfirmed regression in 1.3.x. I believe this worked correctly in 1.2.x as we're getting new problem reports after upgrading, but haven't had time to verify.]

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Emmanuel Venisse added a comment -

I added a test in ProjectSorterTest in r.772047, the issue isn't with the ProjectSorter

Show
Emmanuel Venisse added a comment - I added a test in ProjectSorterTest in r.772047, the issue isn't with the ProjectSorter
Hide
Permalink
Maria Catherine Tan added a comment - - edited

This happens because continuum is disregarding the dependency orders of projects that are not part of a multi-module hierarchy because of the changes made for the group update.

In addition to fixing the order of builds of a non multi-module in a group,

[1] projects within the same group will build in the same "build queue/build agent"

or

[2] projects will build in the same "build queue/build agent" of it's "SNAPSHOT" dependency

[1] is easier to implement and less expensive
[2] can optimize the use of build queues and build agent

Show
Maria Catherine Tan added a comment - - edited This happens because continuum is disregarding the dependency orders of projects that are not part of a multi-module hierarchy because of the changes made for the group update. In addition to fixing the order of builds of a non multi-module in a group, [1] projects within the same group will build in the same "build queue/build agent" or [2] projects will build in the same "build queue/build agent" of it's "SNAPSHOT" dependency [1] is easier to implement and less expensive [2] can optimize the use of build queues and build agent
Hide
Permalink
Maria Catherine Tan added a comment -

The problem with [2] is with Wendy's scenario:

WAR1 and WAR2 can be build in 2 different build queue because they have no dependencies in each other. How will continuum know where EAR should be queued?

So I guess i'll go with [1].

Show
Maria Catherine Tan added a comment - The problem with [2] is with Wendy's scenario: WAR1 and WAR2 can be build in 2 different build queue because they have no dependencies in each other. How will continuum know where EAR should be queued? So I guess i'll go with [1] .
Hide
Permalink
Wendy Smoak added a comment -

I think [1] is fine... most of the time, a project group contains a single multi-module project hierarchy anyway, and it's vitally important that things get built in the right order within a group.

If you were going to do [2], it should notice that the ear depends on both wars and build them all in one queue. That the wars can be build independently is not relevant since they must both be built before the ear. Not everyone uses SNAPSHOT version numbers so that shouldn't be a consideration. Maybe we can leave this optimization open for a future enhancement.

Show
Wendy Smoak added a comment - I think [1] is fine... most of the time, a project group contains a single multi-module project hierarchy anyway, and it's vitally important that things get built in the right order within a group. If you were going to do [2] , it should notice that the ear depends on both wars and build them all in one queue. That the wars can be build independently is not relevant since they must both be built before the ear. Not everyone uses SNAPSHOT version numbers so that shouldn't be a consideration. Maybe we can leave this optimization open for a future enhancement.
Hide
Permalink
Maria Catherine Tan added a comment -

Fixed in

r775693, r775726 of 1.3.x branch
r775729 of trunk

Show
Maria Catherine Tan added a comment - Fixed in r775693, r775726 of 1.3.x branch r775729 of trunk

People

  • Assignee:
    Maria Catherine Tan
    Reporter:
    Wendy Smoak
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: