• New Feature
  • Status: Open
  • 2 Major
  • Resolution:
  • prodmgmt
  • Reporter: ssubbiah
  • August 28, 2008
  • 0
  • Watchers: 1
  • March 19, 2010

Description

Currently our build scripts just verify the existence of the boot-jar to decide whether it needs to build it or not. It needs to be more intelligent than that and figure when to rebuild them. It can check timestamps for one thing thought it might also have to check if the bootjar tool itself has changed after that time.

Also our startup scripts also has to be more intelligent and detect when the boot-jar is not up todate. It should at the least detect that there are some inconsistencies between bootjar and tc.jar

These two problems has bitten us multiple times recently.

Comments

Tim Eck 2008-08-29

I think the check is a little more intelligent than just whether the boot jar exist. I believe it tries to make sure the set of classes it thinks should be in the boot jar are in fact there (and no more). However in the case where say HashMapTC has been changed in the tc.jar, it wouldn’t think the boot needs to be recreated.

I’d go as far as to say that if we can’t be 100% sure that we’ve covered all cases that we should remove this “optimization” of not overwriting it every time. The cost of getting it wrong seems worse than the cost of writing it every time

Saravanan Subbiah 2008-08-30

If we cant do it right we ca just rebuild it but at least we should be doing it only once per test run not for every test that is run. This will greately increase the time to run tests in our monkeys.

Also this doesnt solve the problem for our startup scripts in install env.

I think if we designed some kind of validation check between tc.jar and the bootjar, then we can use it to solve both build and install time issues.