#java #maven
#java #maven
Вопрос:
Этот пример представляет собой гипотетический сценарий, основанный на реальной проблеме. Рассмотрим блок, взятый из pom.xml файл, как указано ниже. В этом сценарии я хочу исключить зависимость artifact-b из artifact-a и повторно импортировать ее с другой версией. Очевидно, что исключенная версия артефакта-b не равна ${product2.version} .
<dependency>
<groupId>com.company.product1</groupId>
<artifactId>artifact-a</artifactId>
<version>${product1.version}</version>
<exclusions>
<exclusion>
<groupId>com.company.product2</groupId>
<artifactId>artifact-b</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.company.product2</groupId>
<artifactId>artifact-b</artifactId>
<version>${product2.version}</version>
</dependency>
Таким образом, когда mvn install команда выполняется для конечного приложения, у меня будет только артефакт-b с ${product2.version} в папке, где приложение хранит jar, собранные из его зависимостей.
Это ожидаемое поведение для моего модуля, но означает ли это также, что методы в artifact-a jar теперь будут вызывать artifact-b jar с ${product2.version} помощью? Если это так (чего я и ожидаю, поскольку целевой репозиторий не включает исключенную версию), что произойдет, если вызываемый метод в artifact-b отличается в новой версии? Проверяет ли это только сигнатуры методов или существуют другие факторы, которые могут вызвать ошибки компиляции / времени выполнения?
Комментарии:
1. Первое неверное предположение: у вас не будет никаких артефактов в вашем
targetкаталоге, только результирующий jar вашего проекта pom, который используетartifact-aиartifact-bв качестве зависимости. Кроме того, исключение в таком случае не требуется, потому что удаленность вашего проекта иartifact-bрешит, что вы будете использоватьartifact-bс версиейproduct2.version…2. Существует исполняемый модуль, который собирает все зависимости и создает работоспособный проект. Я исправлю эту часть в своем вопросе.
3. Это что-то меняет? Как вы собираете зависимости?
4. Перед обновлением я пропустил подробности и просто написал, что все файлы jar, используемые модулем, будут находиться в целевой папке после команды install. На самом деле модуль находится только в целевой папке, а все файлы jar, которые используются приложением, будут находиться в папке lib фактического приложения.
5. Вы не ответили на мой вопрос. С помощью какого плагина / инструмента вы этого добиваетесь? Но это звучит как задание для maven-assembly-plugin…
Ответ №1:
Прежде всего, как сказал хмарбайз, в этом исключении нет необходимости.
Во-вторых, увеличение версии библиотеки может вызвать всевозможные проблемы. Проблемы во время компиляции в основном связаны с сигнатурами методов или отсутствующими классами, но во время выполнения может произойти все, что угодно, в зависимости от изменений, внесенных в исходный код этой библиотеки.
Вы можете просто надеяться, что разработчики библиотеки попытались сохранить все обратно совместимым.
Комментарии:
1. Спасибо за ваш ответ. У меня есть случай, который вызывает проблемы при удалении исключений, но это очень большой проект, и я не могу поделиться. При этом я предполагаю, что в большинстве случаев исключения не нужны, но это не гарантируется. Во-вторых, я прекрасно понимаю, что увеличение версии библиотеки не является хорошей практикой и может вызвать проблемы, но на данный момент мои руки связаны, и все, что я могу сделать, это убедиться, что приложение работает правильно.
2. В вашем случае исключения всегда излишни. Вы можете легко проверить это, запустив
mvn dependency:listс вашим исключением или без него, и вы получите точно такой же результат.3. И я не говорю, что вам не следует увеличивать версию библиотеки, но вам нужно тщательно протестировать, не ломается ли что-нибудь.