2015-09-22 3 views
1

У нас есть базовый POM Maven для всех наших проектов, который протестирован с интеграционными тестами. Однако большая часть кастомизации для Maven релиз плагина:Mock Maven Release

<plugin> 
    <artifactId>maven-release-plugin</artifactId> 
    <configuration> 
     <tagBase>https://my-url</tagBase> 
     <preparationGoals>clean verify org.acme:my-plugin:my-goal</preparationGoals> 
     <completionGoals>org.acme:my-other-plugin:other-goal<completionGoals> 
     <resume>false</resume> 
    </configuration> 
</plugin> 

Я попытался тестирования с помощью «релиз: подготовка» и получил Can't release project due to non released dependencies для родительского POM, который даже не может быть удален с помощью -DallowTimestampedSnapshots=true ,

Я могу проверить через «release: подготовить -DdryRun = true», но это даже не проверяет цели подготовки. Таким образом, единственный способ, которым я мог подумать, - освободить ПОМ, а затем попытаться выпустить произвольный проект. Итак, теперь я на версии 1.0.14 и вернулся примерно 50 раз, и я не думаю, что это правильный путь.

Есть ли способ издеваться над выпуском Maven? Может быть, попросите его пометить местный путь и заставить его совершить там изменения? И он тоже не должен развертываться в нашем Nexus, но я нахожусь в том месте, где я больше не придирчив.

+0

«Интеграционные тесты» вы упомянули о Maven Invoker? – user944849

+0

@ user944849 Да, это так. –

ответ

0

Мне также было необходимо это сделать, и, как и вы, меня не интересовало, как SVN совершает или развертывает удаленное репо - на мой взгляд, проверка была частью других интеграционных тестов. Я подумал, что разработчики maven-release-plugin также будут иметь аналогичную потребность, и действительно, они это сделали. Они написали mock SCM and wagon providers.

Вы можете видеть издевательства, используемые в профиле release plugin POM с id run-its. Обратите внимание, что в config используется setupIncludes, чтобы убедиться в том, что mocks построены и установлены в локальном репо до запуска любых фактических тестов.

Проекты сами должны использовать насмешки. Посмотрите на один из integration tests, чтобы узнать, как определить элемент scm и добавить зависимость от макета Wagon.

Я использовал log verification technique, чтобы убедиться, что в ходе испытаний были выполнены соответствующие исполнения.

Примечание: в каталоге настроек, который я связал, есть 3 mocks. Я обнаружил, что мне нужно использовать только два из них, с суффиксом «-для».

0

Модулируйте процесс с помощью профилей. У вас есть профиль, который запускает ваши действия «подготовить» и профиль, который запускает ваши действия «выполнить», и тестируйте те вместо или перед запуском плагина выпуска. Настройте плагин release, чтобы сделать это, активировав профиль.

+0

Я не хочу тестировать '', я хочу проверить цели подготовки и завершения. –

+1

Которые читают их критическую информацию из тега scm. Вся подготовка выполняется обычным способом, а затем процессом scm. Все выпуски - это операции scm (checkout), за которыми следует mvn -Prelease. Нет scm, ничего не тестировать. – bmargulies

+0

Вы прочитали вопрос? Я изменил эти цели и добавил множество других плагинов, и очень важно посмотреть, работают ли они друг с другом и вызывается в правильном порядке. –

Смежные вопросы