Suppose the following scenario: Excalibur has subprojects foo and bar, where foo depends on bar.
I build foo, which has a dependency on bar.jar, so bar gets built too. So far so good. Now, I do a CVS update. A new feature has been added to foo, which depends on a new method that has been added to bar. Then I try to build foo again. What seems to happen next is: depchecker looks for bar.jar. It exists, since I built it before, so depchecker assumes the dependency is satisfied. Yet the foo build fails, because the new method foo needs is not in the old bar.jar. This failure is difficult to track down (for someone unfamiliar with bar) since depchecker seems to be happy. It would be nice if depchecker could see that some bar src files are newer than bar.jar, and thus delete bar.jar and rebuild. You could argue that since public methods of foo changed, the version number on the jar should have changed, and the dependency entry in the foo subproject's default.properties ought to have changed as well. But I think that this is an unreasonable expectation for subprojects under heavy development. Ryan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
