gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Moving gump forward
Date Tue, 09 Mar 2004 05:25:15 GMT
Daniel F. Savarese wrote:

> In message <200403080826.i288QxPG014618@yoda.savarese.org>, "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.


Mime
View raw message