On Fri, Apr 19, 2002 at 06:11:18PM +0900, Ryan Shaw wrote: > 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.
This is an excellent point, and I hope your email raises awareness of this potential problem. > 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. Or just always run the 'jar' target, and rely on Ant's built-in checks... But while this would be good in some scenarios, it would be disastrous in others, because it introduces extra variables in development. Say that while you're happily working on project foo, someone ELSE modifies project bar. This would be dreadful; you're now at the mercy of anyone who checks in buggy code, or changes the API contract. Say your half-developed foo code starts behaving weirdly; is it your fault, or due to some change in bar? So now, instead of just focusing on improving foo, you must *also* ensure that the modifications in bar are acceptable. Extra variables, extra complexity, and as Frank Herbert might have said, "complexity is the mind-killer". So you absolutely *need* isolation from external changes. Isolation is necessary until the moment when you can say "yes my code works fine", and can tick off that variable. Then, and only then, should you consider the effects of other variable changes. The build system supports this isolation principle in another way. You'll notice that the default target is 'jar', which builds a jar in build/lib/. However, the depchecking system runs the 'dist.lite' target, which builds a jar in dist/, and this is where the "excalibur-*.jar" properties point to. The thinking behind this is that build/lib/*.jar will change on every build, and it's API contracts are not stable enough even for other subprojects to rely on. So there's a dist/ directory, whose jars are *intended* to be relied on by other subprojects. They are relatively stable, and only built on demand by other subprojects, instead of "by accident" when the user types 'ant'. > 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. Only if multiple subprojects are undergoing heavy development together, by one author. I'd suggest that is a relatively infrequent situation compared to that outlined above. --Jeff > Ryan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
