Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Dependency analysis

From time to time it becomes advisable to run an analysis over the pom files to ensure that each sub-projects dependencies are listed and that any needless dependencies are removed.  Maven provides a tool to help with this, but it needs to be treated with circumspection.

  1. Ensure that the (entire) project builds cleanly

  2. Run dependency analysis from the parent directory using the command 'mvn dependency:analyze'.  The key part of the log will look like this 

    mvn dependency:analyze output
    [WARNING] Used undeclared dependencies found:
[WARNING]    org.opensaml:opensaml-profile-api:jar:3.0-SNAPSHOT:compile
[WARNING]    com.google.guava:guava:jar:14.0.1:compile
[WARNING]    joda-time:joda-time:jar:2.2:compile
[WARNING] Unused declared dependencies found:
[WARNING]    net.shibboleth.idp:idp-profile-api:jar:3.0-SNAPSHOT:compile
[WARNING]    org.springframework.webflow:spring-webflow:jar:2.3.2.RELEASE:compile
[WARNING]    org.glassfish:javax.json:jar:1.0.2:runtime
[WARNING]    org.codehaus.janino:janino:jar:2.6.1:compile
[WARNING]    ch.qos.logback:logback-classic:jar:1.0.11:compile
[WARNING]    ch.qos.logback:logback-core:jar:1.0.11:compile
[WARNING]    javax.mail:mail:jar:1.4.7:compile
[WARNING]    org.springframework:spring-context-support:jar:3.2.2.RELEASE:compile
[WARNING]    javax.servlet:servlet-api:jar:2.5:provided
[WARNING]    org.springframework:spring-test:jar:3.2.2.RELEASE:test
[WARNING]    net.shibboleth.utilities:java-support:test-jar:tests:2.0-SNAPSHOT:test
[WARNING]    org.slf4j:jcl-over-slf4j:jar:1.7.5:compile
[WARNING]    org.slf4j:jul-to-slf4j:jar:1.7.5:compile
[WARNING]    org.slf4j:log4j-over-slf4j:jar:1.7.5:compile
[WARNING]    xmlunit:xmlunit:jar:1.4:test
  3. Move any commonly "Used undeclared dependency" into the parent pom (in this case this was guava which occurred as midding in more than 50% of the projects).
  4. Iterate over each subproject (its is probably easiest to do this in the order in the log file - that is from most dependent to least)
    1. Add any missing "Used undeclared dependency"s. Note that sometime dependencies are specified as required for compile when they are only actually required for test.
    2. Carefully remove any "Unused declared dependency"s.  This list will contain modules which are not listed in the pom file and have been inherited, either from the parent pom, or from some dependent module.  Care is needed because
      1. Maven can only analyze static dependency, run time loaded dependencies (such as injecting opensaml-impl into the test scope) need to be listed to allow the test to run, equally several modules (e,g, janino, mail) are needed by the logging providers.
      2. Removing an unused dependency may well break "downstream" poms which require this module to be present.  You may wish to 'skip forward' and add the missing module to these modules at the same time that you remove the explicit dependency.  
        Eclipse is quite good at warning that this has happened, but you need to keep it refreshed if editing outside eclipse.
    3. Run a build and test inside the subproject
  5. Once all subprojects have been completed do a project level build and test
  6. Eyeball all the [changed] poms:
    • (Advisable) Ensure that the ordering of the dependencies is consistent- the order currently used is:

      • Project supplied, versioned dependencies 

        <dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>idp-authn-api</artifactId>
    <version>${project.version}</version>
</dependency>

      • Project supplied, unversioned dependencies: 

        <dependency>
    <groupId>net.shibboleth.ext</groupId>
    <artifactId>spring-extensions</artifactId>
</dependency>

      • Unversions, non-project dependencies: 

        <dependency>
    <groupId>org.apache.velocity</groupId>
    <artifactId>velocity</artifactId>
</dependency>
    • Check for -impl modules being included in -api and -impl modules (except for test scope)
  7. Check in.  It is advisable to provoke a jenkins build at this stage "just in case".

Dependency updates

tbd.  The command of interest is

mvn versions:display-dependency-updates

 

Plugin Maintenance

The simplest way to find what is out of date is to run 

mvn versions:display-plugin-updates

Then edit the requisite pom file (which will usually be the parent pom).  Do a complete build prior to checking is

  • No labels