Re: Sponsor for jaranalyzer package needed
Hi Florian, Florian Grandel said: >> Can it be used to track changes in the method signatures or does it just >> analyze inter-jar depenedencies? > > No, method signatures are not checked. The tool just analyzes inter-jar > dependencies similar to java-propose-classpath within Matthew's > javahelper package. I find this very useful for packaging more > complicated java applications. The tool generates a very nice clickable > HTML-Report with all dependencies and further dependency statistics. See > the XML-part of README.Debian for an example on how to get the HTML. One more thought: did you check that the logic is the same between Matthew's javahelper and your tool? Is code sharing an option? The worse that could happen to packagers would be different results from those two tools; I can already imagine the mess... ;-) Thanks, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor for jaranalyzer package needed
On Tue Jul 08 10:12, Eric Lavarde - Debian wrote: > Hi Florian, > > Florian Grandel said: > >> Can it be used to track changes in the method signatures or does it just > >> analyze inter-jar depenedencies? > > > > No, method signatures are not checked. The tool just analyzes inter-jar > > dependencies similar to java-propose-classpath within Matthew's > > javahelper package. I find this very useful for packaging more > > complicated java applications. The tool generates a very nice clickable > > HTML-Report with all dependencies and further dependency statistics. See > > the XML-part of README.Debian for an example on how to get the HTML. > One more thought: did you check that the logic is the same between > Matthew's javahelper and your tool? Is code sharing an option? > The worse that could happen to packagers would be different results from > those two tools; I can already imagine the mess... ;-) > Well, neither of them can be used in an automated fashion due to possible clashes in jars, so they are both just hints to the maintainer when originally packaging the software and figuring out the dependencies. I don't think there's a big problem with the two existing together and possibly giving different results. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Sponsor for jaranalyzer package needed
Hi Eric, One more thought: did you check that the logic is the same between Matthew's javahelper and your tool? Is code sharing an option? The worse that could happen to packagers would be different results from those two tools; I can already imagine the mess... ;-) No. I have not compared the logic of both tools in a systematic way. I however tried out the new tool on a jar that has a build dependency not discovered by java-propose-classpath. (Compare last paragraph of [1]) Both tools didn't show the dependency. So at least they are consistent in that respect. ;-) As I am using both tools just to facilitate my own packaging work I won't be able to dive in now to find out why the dependency is not discovered. Probably I'll find out sooner or later anyway. I think both tools have their respective uses in different contexts (one to do broad impact/dependency analysis and one to get a readily usable classpath proposition). If one of the packagers finds different results then I'll certainly help to analyze and interpret the difference. Florian [1] http://lists.debian.org/debian-java/2008/06/msg00042.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
