gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <>
Subject Re: [RT] Moving gump forward
Date Mon, 08 Mar 2004 08:45:48 GMT

In message <>, "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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message