Scheduled build loses track of proper reactor order after a release

If the build order is dependent on the previous build state of a project, I'd like to suggest resetting the build state of newly released projects so the build order won't get messed up. Besides, the project was already released and the build state refers to the previous version.

Wdyt?

I tried addressing this issue with my suggestion, but it didn't work. I built a multimodule project (with inter-module deps), and released it. When the scheduled build triggered, nothing was built. Seems I was wrong to rely on the build state in determining the build order. But the weird thing I observed was the way scheduled builds treat projects with changes, as it was different when forcing a build. I can't say anything definite yet, I just based it on the event logs. I'm digging deeper into this.

Attached a tarball of the multimodule project I used for this issue (multimodule-project.tar.gz).

It contains:

multimodule-parent
  |
  +-- submodule-one
  |
  +-- submodule-two
  |
  +-- submodule-three

three depends on one, one depends on two. So the the build order should go parent->two>one->three.

Some more observations:

1. Added the multimodule project in continuum
2. forced a build of the project group (build order was correct)
3. released the project group
4. wait for a scheduled build (build order was correct, but skipped building the parent)

Fixed in rev 699165

http://svn.apache.org/viewvc?view=rev&revision=699165 includes:

 +        //CONTINUUM-1815: additional check for projects recently released
 +        if ( !continuumProject.getVersion().equals( project.getVersion() )
 )
 +        {
 +            getLogger().info( "Found changes in project's version ( maybe project was recently released ), building" );
 +            return true;
 +        }

This is causing problems in CONTINUUM-1979, because the release triggers the next scheduled build (which is a release) in an endless loop.

We need to revert changes made to this

I tried this in the continuum-flat-multi-module branch and using a single checkout directory for a multi-module project fixes this problem. So i'm changing the fix version for this to 1.4.0