1

I am in the process of updating a large set of legacy java applications. The current builds use ant with its dependencies coming from each project's lib directory. The dependencies are part of each project and checked in to source control. The purpose of the updates is to convert the builds to gradle and use a maven repository for dependency management. For simplicity, the legacy builds copied dependencies from other project's lib directories using an ant construct like:

<fileset dir="../anotherlegacyproject/lib">
    <include name="**/*.jar" />
</fileset>

This approach is used for both compile and runtime dependencies. While this works, it leads to bloat of the deployment artifacts because of the many jars included which are not necessary at runtime. For example, many of the projects include junit, hamcrest, and jaxb-xjc in the runtime even though they are only used for compile or test. Most of the projects create both a zip file and an RPM containing deployable applications. I would like to only include the required runtime dependencies in the RPMs.

I am trying to determine a reliable method for identifying these unused runtime dependencies.

I have reviewed the post: How to find\remove unused dependencies in gradle but this does not address unused runtime dependencies. I have tried using the following gradle plugins, none of which identify unused runtime dependencies:

  • github.com/nebula-plugins/gradle-lint-plugin
  • github.com/wfhartford/gradle-dependency-analyze
  • docs.gradle.org/current/userguide/jdepend_plugin.html

I am open to any solution that will reliably work, but my preferences would be in this order:

  1. An existing gradle plugin
  2. Code that could be incorporated into the build.gradle file or groovy code packaged as a plugin
  3. Anything else
Community
  • 1
  • 1
shortfuse
  • 11
  • 1
  • 3
  • This is a somewhat involved problem - what if your code performs runtime reflection? Even static analysis wouldn't help you. – Oliver Charlesworth Aug 13 '16 at 14:29
  • But honestly, a source-controlled lib directory full of Jars is gross anyway. If you were to take the plunge and replace these with Maven dependencies, you'd be substantially better off. (And the work involved in doing that would make your current problem moot.) – Oliver Charlesworth Aug 13 '16 at 14:32
  • Moot in the sense that you're going to have to evaluate each Jar one-by-one anyway (in order to figure out its equivalent Maven coordinate). It's not substantially more effort to also figure out whether it's required for `compile` or `testCompile`. – Oliver Charlesworth Aug 13 '16 at 14:39
  • I have already done all the work of determining maven coordinates. I have reproduced the legacy RPMs in gradle using all of the same dependencies as the legacy projects. The problem I am trying to solve is runtime, not compile or testCompile. The junit reference was only an example. A more realistic example would be org.elasticsearch:elasticsearch:2.3.2 which has 37 dependencies, only 5 of which are test. I don't want to continue to include the other 32 dependencies if they are not utilized at runtime. – shortfuse Aug 13 '16 at 15:24
  • In general, `runtime` is going to be a superset of `compile`. Only caveats I can think of are (a) you're talking about a `provided`-like concept (some framework provides some dependencies at runtime) or (b) you want to optimise away transitive dependencies corresponding to code-paths that are never exercised at runtime. – Oliver Charlesworth Aug 13 '16 at 15:29
  • I am mostly looking for your "b" option. I have finished the first phase of the conversion which was to reliably reproduce the legacy RPMs using gradle w/ maven dependencies. Now in the second phase, I want to trim down those unnecessary runtime dependencies. – shortfuse Aug 13 '16 at 15:44
  • 1
    Ok, I think that's basically similar to my initial comment - this doesn't feel like something that's achievable by static means. – Oliver Charlesworth Aug 13 '16 at 15:46

1 Answers1

0

Recently we migrated some project from 1.6 to 1.8, needed to find out unused jar. I was trying to use some plugin and tool but could not solve my issue. Over stack overflow I got some insight to fix this issue. Below are the steps to find out unused jar in project.

  1. First you need to take latest EAR/WAR of your module. Suppose you module name is CheckDependency, so take latest EAR/WAR and get it out lib folder.
  2. Now in eclipse replace lib folder of your module with new one, which taken from EAR/WAR.
  3. Eclipse go to your module and select Gradle(STS)[This should be installed in your machine]-->Hit Task Quick Launcher-->Select projectTattleTaleReport It will generate all report in you target folder with name tattleReport
Saurabh
  • 41
  • 8