Алгоритм устранения неполадок «Проблемы с Maven не работают для меня»

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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