Hey Marko, In my experience, there are a few common reasons why libraries do not end up in Debian:
1. Lack of time from maintainers: Debian is largely a volunteer effort, and as a result, sometimes things don't end up in Debian simply because people lack the time to package it. You can help here by learning to create packages (the IRC channel can be helpful, OFTC #debian-java) and requesting review/sponsorship 2. Licensing problems: either a library or one of its dependencies cannot be packaged due to problems with licensing (e.g. a library depends on non-free software to build it, for example, or copyright/license statements are missing) 3. Unawareness: Nobody has asked for the package before, so we simply weren't aware that someone wanted a package. So your email helps :) 4. API stability: If upstream does not maintain API/ABI stability, then that may make it difficult for maintainers to handle the package (related to #1) causing the package to be dropped :( 5. Not required by any applications: In general, we package libraries when they are needed by an application. I think this is mostly due to #1 - if it's labor intensive to package something, then it makes more sense only to package libraries that are needed by applications, since those are more likely what users will want to download. At least this was true for the Debian Perl Group, I'm not sure if the Java group has similar constraints/thoughts. For 2 and 3, you can verify by checking outstanding wnpp bugs: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp;dist=unstable -- I did a quick search and didn't find it listed there, so maybe a good first start is to file an RFP package and Cc this list. I think all packages that people use are worth adding to Debian, regardless of whether libraries accomplishing a similar purpose have already been packaged. Now, for alternatives to Soot, perhaps JDepend fills a similar purpose? https://packages.debian.org/sid/libjdepend-java Other great static code analysis tools (not just for doing call-tree analysis) include: FindBugs: https://packages.debian.org/sid/findbugs PMD: https://pmd.github.io/ -- sadly, not packaged either :( Checkstyle: https://github.com/checkstyle/checkstyle -- not packaged Sonar: http://www.sonarqube.org/ -- not packaged In general, I think for development, people take advantage of Java's mature toolchain & ecosystem (Ant+Ivy, Maven, Gradle) rather than use Debian packages, so that may explain why we don't have as many. Jonathan On Sat, Nov 14, 2015 at 1:30 AM, Marko Dimjašević <[email protected]> wrote: > Dear all, > > I was wondering if a static code analysis tool has been packaged for > Debian. For example, I'm looking for something that would generate a > call-graph, i.e. which Java methods call a particular method and the > other way around. > > A tool that comes to my mind is Soot [1]. As far as I can tell, it is > free software (licensed under LGPLv2.1). However, I don't see it > packaged for Debian. How come? I know compilers and IDEs provide some > static code analysis, but there are other than things done by the > compilers and IDEs a Java developer would be interested in, such as the > call-graph case mentioned above. I want to use this information (the > call-graph) in a program analysis tool. > > Basically, I just want to check if there is already a tool for static > code analysis for Java along the lines described above, which is present > in Debian and that I am not aware of. If not, packaging Soot sounds like > the way to go. > > > [1] https://github.com/Sable/soot > > > -- > Kind regards, > Marko Dimjašević > http://dimjasevic.net/marko > > -- Cheers, Jonathan
