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.
yep, I had the exact same thoughts about modifying a compiler, but as i said previously, I would love to think at language-agnostic ways to do this.
this said, it would be just marvellous if gump could spot dependencies transparently by analzying the classloading patterns of the compiler.
that would allow gump to suggests improvements to the various gump descriptors automagically.
but this modification is not easy, given that we need to change ant for this.
Stefan, any talks in ant-land about using eclipse JTD compiler instead of javac for the <javac> task? or, eventually, how can gump execute ant forcing the <javac> task to be our own?
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
