Path: csiph.com!news.mixmin.net!newsreader4.netcologne.de!news.netcologne.de!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod From: Jonathan Yu Newsgroups: linux.debian.maint.java Subject: Re: Static code analysis tool in Debian Date: Sat, 14 Nov 2015 23:00:02 +0100 Message-ID: References: X-Original-To: =?UTF-8?B?TWFya28gRGltamHFoWV2acSH?= X-Mailbox-Line: From debian-java-request@lists.debian.org Sat Nov 14 21:50:56 2015 Old-Return-Path: X-Amavis-Spam-Status: No, score=-5.597 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FOURLA=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, LDO_WHITELIST=-5, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no autolearn_force=no X-Policyd-Weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_BL_NJABL=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .gmail. - helo: .mail-ob0-x244.google. - helo-domain: .google.) FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -7 Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=oKQMm4lC0vC1Yo+eiqoxJjnn1wpnGeCDzSLhrSV5vCE=; b=Mn2WmG1wRsJXeLqi+OwqDLbXRXgyq1xOpBNvS4RYZv8mXeycR3vE8ZLK6AbM8kBpla jWZPcjziuMmNzCW6tt0i/HHCwDAwQpS+/qzS33HQPNwXxkAj1PU4uT0zV/Sg1M3lbbjs DctyypmLWLoAL3HXkx4IbGw4admWsk+8uXABPyAPnd75DsnXTbKe+i6TBk418CEJu4J6 54uC51vZ8uJW6gsoIvSUypQqxLoRl2C+ktYfQoF4hBOgEJebPnfg7Os7n4G2IAMh13pn f7axjjxLkJ7ytuigRnudKYqhUEGFKExO8Hadmfxfdn9bPih5+Lraga7b3ockw5U17cIS fmTQ== X-Received: by 10.60.176.36 with SMTP id cf4mr18666124oec.9.1447537837835; Sat, 14 Nov 2015 13:50:37 -0800 (PST) MIME-Version: 1.0 Sender: robomod@news.nic.it X-Google-Sender-Auth: 3OYwyV-29zODzjeo_trcFi-UGnk Content-Type: multipart/alternative; boundary=089e0115f3c49f8f510524872abc X-Mailing-List: archive/latest/18867 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/CAMDxSEg8mUn0e0deYTYczC5RTrJ5pLHqJZRFGXizoGX0q-zZPA@mail.gmail.com Approved: robomod@news.nic.it Lines: 198 Organization: linux.* mail to news gateway X-Original-Cc: Debian Java Maintainers X-Original-Date: Sat, 14 Nov 2015 16:49:58 -0500 X-Original-Message-ID: X-Original-References: <1447482612.3260.46.camel@dimjasevic.net> X-Original-Sender: jonathan.i.yu@gmail.com Xref: csiph.com linux.debian.maint.java:8548 --089e0115f3c49f8f510524872abc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=3Dwnpp;dist=3Dunstable --= 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=C5=A1evi=C4=87 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=C5=A1evi=C4=87 > http://dimjasevic.net/marko > > --=20 Cheers, Jonathan --089e0115f3c49f8f510524872abc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Marko,

In my experience, there are = a few common reasons why libraries do not end up in Debian:

<= /div>
1. Lack of time from maintainers: Debian is largely a volunteer e= ffort, 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 t= o create packages (the IRC channel can be helpful, OFTC #debian-java) and r= equesting review/sponsorship

2. Licensing problems= : either a library or one of its dependencies cannot be packaged due to pro= blems 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 maintai= n API/ABI stability, then that may make it difficult for maintainers to han= dle the package (related to #1) causing the package to be dropped :(
<= div>
5. Not required by any applications: In general, we pack= age libraries when they are needed by an application. I think this is mostl= y due to #1 - if it's labor intensive to package something, then it mak= es more sense only to package libraries that are needed by applications, si= nce those are more likely what users will want to download.=C2=A0 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, yo= u can verify by checking outstanding wnpp bugs:=C2=A0https://bugs= .debian.org/cgi-bin/pkgreport.cgi?pkg=3Dwnpp;dist=3Dunstable -- I did a= quick search and didn't find it listed there, so maybe a good first st= art is to file an RFP package and Cc this list.

I = think all packages that people use are worth adding to Debian, regardless o= f whether libraries accomplishing a similar purpose have already been packa= ged.

Now, for alternatives to Soot, perhaps JDepen= d fills a similar purpose?=C2=A0https://packages.debian.org/sid/libjdepend-java
<= div>
Other great static code analysis tools (not just for doi= ng call-tree analysis) include:


PMD:=C2=A0https://pmd.github.io/ -- sadly, not packaged either :(<= /div>

Checkstyle:=C2=A0https://github.com/checkstyle/checkstyle -- not pac= kaged

Sonar:=C2=A0http://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 D= ebian packages, so that may explain why we don't have as many.

Jonathan

On Sat, Nov 14, 2015 at 1:30 AM, Marko Dimja=C5=A1evi= =C4=87 <marko@dimjasevic.net> 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=C5=A1evi=C4=87
http://dimjasevic.net/marko




--
Cheers,

Jonathan
--089e0115f3c49f8f510524872abc--