剖析Maven

本文介绍了剖析Maven的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

是否有一些工具可以自我描述Maven构建过程，以便我可以了解构建花费最多时间的地方?

Are there tools that will profile the Maven build process itself so that I can see where the build is spending most time?

关于Maven 3.0.3和3.0b1，我们遇到了一些问题.与3.0.3(9m00s)相比，我们的项目在3.0b1(3m30s)下的构建速度要快得多.使用3.0b1，构建速度大约提高了63％(如果我的数学正确的话).

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).

我尝试搜索有关Maven 3的性能比较和性能问题，但是找不到任何东西.

I tried searching for performance comparisons and performance issues regarding Maven 3, but was unable to find anything.

更新

我通过查看Maven来源进行了更多研究，这是我发现的:

I did some more research by looking at the maven sources and this is what I found out:

在使用jconsole时，我看到大部分时间(在3.0.3中)都花在了DefaultProjectDependenciesResolver.java内部.因此，我将源代码下载到3.0b1和3.0.3中，以查看发生了什么.我注意到在3.0.3中有两个版本的类.一个在org.apache.maven.project中，而另一个在org.apache.maven中.还似乎在3.0.3中使用了前者.在遍历代码的过程中，我看到到达该语句的时间花费了大部分时间:

While using jconsole, I saw that most of the time (in 3.0.3) is spent inside DefaultProjectDependenciesResolver.java. 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 org.apache.maven.project, while the other is in org.apache.maven. 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:

node = repoSystem.collectDependencies( session, collect ).getRoot();

在3.0b1中，代码执行以下操作:

In 3.0b1, the code does:

ArtifactResolutionResult result = repositorySystem.resolve( request );

我还注意到respositorySystem是RepositorySystem类型，具体实现是LegacyRepositorySystem.我假设在Maven 3处于测试版之前一直在使用此功能，直到创建了新的实现?回到3.0.3，collectDependencies方法驻留在DefaultRepositorySystem.java中，而DefaultRepositorySystem.java是org.sonatype.aether.impl.internal的一部分.最终这会在DefaultDependencyCollector.java内的collectDependencies中调用collectDependencies，这也是org.sonatype.aether.impl.internal的一部分.我假设这就是依赖关系图的构建方式.

I also noticed that respositorySystem is of the type RepositorySystem, and the concrete implementation is LegacyRepositorySystem. 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 collectDependencies method lives in DefaultRepositorySystem.java which is part of org.sonatype.aether.impl.internal. This eventually calls collectDependencies inside DefaultDependencyCollector.java which is also part of org.sonatype.aether.impl.internal. I'm assuming that this is how the dependency graph is built.

我现在想知道这是因为我们的依存关系是如何构建的.以前有没有人见过这种行为?

I'm now wondering it is because of how our dependencies are structured. Has anyone seen this kind of behavior before?

更新

JIRA中有关于此问题的问题和建议的修复程序.我已将详细信息发布为答案.

There is an issue in JIRA about this issue along with a suggested fix. I've posted the details as an answer.

更新

问题是由于在Maven 3.0.3(1.11)中使用的以太版本引起的.以太1.12版解决了此问题.我签出了Maven 3.0.3的源代码，并编辑了POM以将以太版本从1.11更改为1.12.然后，我从源代码构建了maven，并用构建的版本替换了当前版本.减少了构建时间.

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.

如果您不想从源代码构建Maven，则可以将Maven的lib目录中的以太库替换为1.12版本.那也应该工作.

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.

我不确定此更改是否会使其变为3.0.4，因为行家开发人员表示，许可更改已从以太1.11更改为以太1.12，因此他们仍在讨论中.

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.

the

剖析Maven

问题描述

推荐答案