In message <[EMAIL PROTECTED]>, "Daniel F. Savarese " writes: >Another heuristic approach that would work for Java projects at >least, would be to analyze the build failure messages. Usually >they'll reference a class or class member/method that is in >a dependent code base. Develop an evolving library of patterns >to extract the offending methods/classes/etc. and then discover >what jar they came from.
Right after I sent that I realized that there's a more effective variation of this idea. The compiler often knows exactly why a compile failed. It should be possible to extend one of the several Java compilers out there with some Gump-aware code that will map the package an offending programming construct belongs to back to the project it belongs to. That doesn't help you directly in the case when an API artifact is removed or renamed (although it does help when a method signature changes), but it does help you narrow down the change based on the packages imported by the file. So you can limit the scope of dependencies on which you apply the brute force comparative build approach. In fact, for Java code, instead of going to the trouble of enhancing the compiler, it may be enough just to look at the packages in the file(s) that failed to compile based on the error message spewed by the compiler. Maybe it's better to think about how a human goes through the process of tracking down the source of a failure and see how that can be emulated. Again, that's assuming that 100% accurate solutions are too computationally expensive to be practical. That's it for my RT contribution. I'm on EST. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
