...

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 

   Code Block
   title 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 

       Code Block
       language html/xml
       <dependency> <groupId>${project.groupId}</groupId> <artifactId>idp-authn-api</artifactId> <version>${project.version}</version> </dependency>

     • Project supplied, unversioned dependencies: 

       Code Block
       language html/xml
       <dependency> <groupId>net.shibboleth.ext</groupId> <artifactId>spring-extensions</artifactId> </dependency>

     • Unversions, non-project dependencies: 

       Code Block
       language html/xml
       <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".

Plugin Maintenance

• For each affected pom, compare the version of the plugin against its currently published version.  This pageis a useful reference
• Run a complete build
• Check in.  It is advisable to provoke a jenkins build at this stage "just in case".

It can be useful to do a grep for the test '<plugin' in all files called pom in the checked out tree, since not all plugins are defined in the parent pom

 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