Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 329665 - build.stamp should be propagated to sub-builds
Summary: build.stamp should be propagated to sub-builds
Status: CLOSED FIXED
Alias: None
Product: Virgo
Classification: RT
Component: virgo-build (show other bugs)
Version: 2.2.0.M01   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.0.0.M01   Edit
Assignee: Steve Powell CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-08 06:27 EST by Glyn Normington CLA
Modified: 2011-02-28 10:35 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Glyn Normington CLA 2010-11-08 06:27:43 EST

    
Comment 1 Steve Powell CLA 2010-11-08 10:07:45 EST
Embarrassing problem here:

When full process-isolated sub builds were initiated (to overcome ivy permgen leaks) we had to explicitly pass properties to the sub build (cannot use the subant task mechanisms).

We failed to pass enough parameters -- in particular we (originally) omitted to pass ${timestamp} so the sub-project builds got a different bundle version (including a timestamp) from each other and from the top-level build.

This was fixed, but then we discovered that 'ripplor' builds failed to generate the correct build.stamp for the sub-project builds -- this was "fixed" by passing ${build.stamp} but unfortunately propagated before testing (hard to do with a ripple) and it wasn't a fix at all!

Finally we passed ${bundle.version} which turned out to be the correct parameter for a ripple.  I ought to check that ordinary builds work properly, too.

. . .
Comment 2 Steve Powell CLA 2010-11-08 10:23:07 EST
. . .

OK local builds still OK.  
virgo-build/ version 1.38 propagated to master branches, and to 2.1.x and 1.1.x branches.

Ripple on master (from util) is running OK now.
Comment 3 Chris Frost CLA 2010-12-10 09:47:36 EST
Fixed