Алгоритм устранения неполадок "Maven не работает для меня"

Question

Одной из наиболее распространенных и раздражающих проблем, с которыми я сталкиваюсь в Maven, является сбой / прохождение процесса сборки в зависимости от того, кто, когда и на каком компьютере выполняет процесс.

Более формально - в идеалеworld Я ожидаю, что процесс сборки будет повторяться.Как программист, я бы сказал, что я ожидаю, что процесс сборки будет похож на чистую функцию исходного кода и ресурсов, являющихся входными данными для сборки и "средой" - я ожидал бы, что он будет возвращать тот же результат в любое время ивезде, где я «оцениваю» его, используя «фиксированную среду», и я ожидаю (скорее, желаю), чтобы все в команде имели одинаковую «фиксированную среду».

В реальном мире любая «среда»"меняется со временем или изменяется между машинами разработчика, возможно, потому что он включает в себя некоторые зависимости, которые никто не ожидает и не осознает.

Чего я пытаюсь добиться, задавая этот вопрос, так это нахождение / определение алгоритма / процедуры или проверкисписок для устранения неисправностей, которые невозможно повторить. Процессы сборки Maven. Предположим, у нас есть две отдельные машины A и B с одной и той же ОС, и что мы собираем на них одну и ту же версию нашего приложения, но они дают разные результаты (например, одинуспешно, и один не удается).Где / как следует искать различия между этими двумя «средами».

Вот некоторые шаги, которые я обычно использую:

1. сравните эффективные POM, полученные с помощью mvn help:effective-pom
2. сравнивать исполняемые версии mvn + другие задействованные инструменты (например, jdk)
3. сравнивать настройки среды (полученные под Windows с помощью команды set командной строки)
4. сравнивать settings.xml файлы из дома пользователякаталоги
5. сравнить пути к классам, созданные с помощью mvn dependency:build-classpath
6. удалить репозиторий или даже оба репозитория

Есть идеи, что еще может дать ценную информацию?Может быть, есть лучший способ, которого я просто скучаю ...

Answer 1

Давай сделаем тост по-американски: сожги, а я поцарапать. --W. Эдвардс Деминг.

Вместо того, чтобы искать алгоритм для устранения неполадок в ваших неповторяемых сборках, исправьте основную причину , сделайте их повторяемыми, следуя рекомендациям (сборки Maven на 100% повторяются, если вы правильно используете): *

• использовать одну и ту же версию Maven на всех машинах данного проекта (распространять упакованную версию)
• использовать ту же версию JDK (по крайней мере, ту же версию для данного проекта)
• блокирует версии плагинов в ваших poms для воспроизводимости сборки
• применять вышеуказанные правила с помощью Maven Enforcer Plugin
• использовать корпоративный репозиторий (и только корпоративный репозиторий)
• избегайте создания непереносимых сборок, добавляя не специфичные для пользователя вещи в ~/.m2/settings.xml
• поставить все под контроль версий (эффективный pom должен быть одинаковым на всех машинах)
• запускать чистые сборки на сборочном компьютере (ссылка)

Я использовал Maven в организациях с сотнями разработчиков, не испытывая проблем, которые вы описываете. На самом деле, и я сожалею, что проблемы, с которыми вы сталкиваетесь, не являются ошибкой Maven, а являются результатом плохой практики разработки (я не хочу быть грубым, но это правда).

Answer 2

Не совсем ответ per se , но мы каждую неделю удаляем весь локальный репозиторий на сборочной машине.

Машина сборки также ограничена небольшим набором локальных репозиториев и репозиториев, которые разработчики не могут редактировать.

Сначала у нас было много сборок, которые просто перестали работать после удаления репо. Теперь это ежемесячная проблема. Это имеет тенденцию к проблеме через месяц.

Это способствовало ряду хороших практик по блокировке номеров версий, версий плагинов, использованию профилей для локальных сборок, использованию исключений при необходимости и добавлению сторонних файлов jar в нужные места.

Answer 3

Отследите, что вы делаете, и сможете отслеживать, что делают разработчики:

1. Создание машины сборки (для выпусков сборки), документирование каждого установленного программного обеспечения и каждого выбранного параметра конфигурации
2. Частные машины сборки должны быть настроены таким же образом, чтобы обеспечить максимальную надежность работающей сборки
3. При сбое частной сборки перечислите программное обеспечение и конфигурации и сравните их с конфигурацией выпуска. Различия считаются неподдерживаемыми и должны быть исправлены для достижения максимальной вероятности успешного построения

Answer 4

Я видел множество сборок Maven на разных машинах из-за разных версий Maven или Java и связанных с ними ошибок или функций. Я даже видел, как сборки терпят неудачу и проходят на одной машине, например, когда встроенный в командной строке и встроенный в IDE.

Если вызываются инструменты командной строки, вы можете обнаружить, что они зависят от платформы или машины. Это особенно заметно в задачах пакета, которые создают файлы .dmg на Mac или .msi на компьютерах с Windows, и в этих ОС должна быть выполнена упаковка для создания определенных файлов.

Кодирование файлов ресурсов и исходных файлов вызывало у меня проблемы в прошлом. Проверка того, что свойство project.build.sourceEncoding установлено, выглядит как полезная информация. Скорее нелогично, это, кажется, используется при копировании или фильтрации ресурсов, но игнорируется при работе с исходными файлами, IIRC.