title: Profiling Maven
body: <p>Are there tools that will profile the Maven build process itself so that I can see where the build is spending most time?</p>
  
  <p>We're having issues at work with respect to Maven 3.0.3 and 3.0b1. Our project builds much faster under 3.0b1 (3m30s) compared to 3.0.3 (9m00s). With 3.0b1 the build is approximately 63% faster (if my math is right).</p>
  
  <p>I tried searching for performance comparisons and performance issues regarding Maven 3, but was unable to find anything.</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>I did some more research by looking at the maven sources and this is what I found out:</p>
  
  <p>While using jconsole, I saw that most of the time (in 3.0.3) is spent inside <code>DefaultProjectDependenciesResolver.java</code>. So I downloaded the source to both 3.0b1 and 3.0.3 to see what's happening. I noticed that in 3.0.3 there are two versions of the class. One is in <code>org.apache.maven.project</code>, while the other is in <code>org.apache.maven</code>. It also appears that in 3.0.3, the former is being used. While stepping through the code, I saw that bulk of the time is spent when it reaches this statement:</p>
  
  <pre><code>node = repoSystem.collectDependencies( session, collect ).getRoot();
  </code></pre>
  
  <p>In 3.0b1, the code does:</p>
  
  <pre><code>ArtifactResolutionResult result = repositorySystem.resolve( request );
  </code></pre>
  
  <p>I also noticed that <code>respositorySystem</code> is of the type <code>RepositorySystem</code>, and the concrete implementation is <code>LegacyRepositorySystem</code>. I'm assuming that this was being used while the Maven 3 was in beta until the new implementation was created? Going back to 3.0.3, the <code>collectDependencies</code> method lives in <code>DefaultRepositorySystem.java</code> which is part of <code>org.sonatype.aether.impl.internal</code>. This eventually calls <code>collectDependencies</code> inside <code>DefaultDependencyCollector.java</code> which is also part of <code>org.sonatype.aether.impl.internal</code>. I'm assuming that this is how the dependency graph is built.</p>
  
  <p>I'm now wondering it is because of how our dependencies are structured. Has anyone seen this kind of behavior before?</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>There is an <a href="https://jira.codehaus.org/browse/MNG-5125" rel="noreferrer">issue</a> in JIRA about this issue along with a suggested fix. I've posted the details as an answer.</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>The problem is due to the version of aether that's used in maven 3.0.3 (1.11). Version 1.12 of aether fixes this problem. I checked out the source to maven 3.0.3 and edited the POM to change the version of aether from 1.11 to 1.12. I then built maven from source and replaced my current version with the version I built. The reduction in build-times is dramatic.</p>
  
  <p>If you don't want to build maven from source, you can replace the aether libraries that are in maven's lib directory with 1.12 version. That should work as well.</p>
  
  <p>I'm not sure if this change is going to make it into 3.0.4, because the maven developers said that there are licensing changes going from aether 1.11 to aether 1.12, and so they're still discussing it.</p>