Подтвердить что ты не робот

Профилирование Maven

Существуют ли инструменты, которые будут обрабатывать сам процесс сборки Maven, чтобы я мог видеть, где сборка тратит больше времени?

У нас возникают проблемы с работой над Maven 3.0.3 и 3.0b1. Наш проект развивается намного быстрее, чем 3.0b1 (3m30s) по сравнению с 3.0.3 (9m00s). С 3.0b1 сборка примерно на 63% быстрее (если моя математика права).

Я попытался найти сравнения производительности и производительности в отношении Maven 3, но не смог ничего найти.

UPDATE

Я сделал еще несколько исследований, посмотрев на источники maven, и вот что я узнал:

При использовании jconsole я видел, что большую часть времени (в 3.0.3) тратится внутри DefaultProjectDependenciesResolver.java. Поэтому я загрузил источник в 3.0b1 и 3.0.3, чтобы узнать, что происходит. Я заметил, что в версии 3.0.3 есть две версии класса. Один находится в org.apache.maven.project, а другой - в org.apache.maven. Также представляется, что в версии 3.0.3 используется первая. Пройдя через код, я увидел, что основная часть времени расходуется, когда он достигает этого утверждения:

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

В версии 3.0b1 код выполняет:

ArtifactResolutionResult result = repositorySystem.resolve( request );

Я также заметил, что respositorySystem имеет тип RepositorySystem, а конкретная реализация - LegacyRepositorySystem. Я предполагаю, что это использовалось, пока Maven 3 был в бета-версии, пока не была создана новая реализация? Возвращаясь к 3.0.3, метод collectDependencies находится в DefaultRepositorySystem.java, который является частью org.sonatype.aether.impl.internal. В итоге он вызывает collectDependencies внутри DefaultDependencyCollector.java, который также является частью org.sonatype.aether.impl.internal. Я предполагаю, что так построен граф зависимостей.

Теперь мне интересно, из-за того, как структурируются наши зависимости. Кто-нибудь видел такое поведение раньше?

UPDATE

В JIRA существует проблема , а также предлагаемое исправление. Я отправил детали в качестве ответа.

UPDATE

Проблема связана с версией эфира, используемой в maven 3.0.3 (1.11). Эта проблема решена в версии 1.12 эфира. Я проверил источник на maven 3.0.3 и отредактировал POM, чтобы изменить версию эфира с 1.11 до 1.12. Затем я построил maven из исходного кода и заменил мою текущую версию версией, которую я построил. Сокращение времени сборки является драматичным.

Если вы не хотите создавать maven из исходного кода, вы можете заменить библиотеки эфира, которые находятся в каталоге maven lib с версией 1.12. Это также должно работать.

Я не уверен, изменит ли это изменение в 3.0.4, потому что разработчики maven заявили, что есть изменения лицензий, идущие от эфира 1.11 до эфира 1.12, и поэтому они все еще обсуждают его.

4b9b3361

Ответ 1

Maven - это просто приложение Java, поэтому я предлагаю вам запустить его с помощью инструмента профилирования, такого как YourKit или JProfiler и проанализировать его производительность во время выполнения. Вы также можете использовать JVisualVM для извлечения информации о производительности во время выполнения.


В целом, я считаю, что разработчикам Maven было бы интересно узнать об этой регрессии производительности. Пожалуйста, откройте билет в Maven Jira или опубликуйте в список разработчиков Maven

Ответ 2

Что касается общего вопроса о профилировании сборки Maven, то это Codehaus JIRA issue, в котором содержится исправление для выводя время выполнения Mojos. К сожалению, он еще не был включен в Maven.