Обработка символических ссылок в плагине Maven Resources
В src/test/resources
В папке проекта Maven есть относительная символическая ссылка.
С 2.6
версия плагина, актуальный файл скопирован.
После обновления до 3.0.1
версия, он копирует ссылку вместо файла, и при последующем запуске (без очистки) происходит сбой (mvn -e показывает, что это из-за FileAlreadyExistsException
).
Есть ли опция конфигурации для восстановления поведения из предыдущей версии?
Я согласен, иметь ссылку в качестве тестового ресурса - действительно плохая идея.
2 ответа
Это известная ошибка в maven-resources-plugin
: MRESOURCES-237 Плагин ресурсов для обработки символических ссылок изменился в 3.0.x, нарушил существующее поведение, нефиксировано, но известно в течение 1½ лет.
К сожалению, нет (пока) опции конфигурации. Введение (и использование по умолчанию "следовать символическим ссылкам" вместо сохранения их копий) решило бы эту проблему.
На данный момент единственным решением является понижение maven-resources-plugin
, Я также обновил с версии 2.6 и только что понизил до 2.7 (последняя из серии 2.x), и могу подтвердить, что он работает с этой ошибкой и правильно копирует содержимое символических ссылок.
Обновление: из-за проблемы "Пометить недействительно" ( ошибка в maven-фильтрации) вы должны рассмотреть возможность использования версии 2.6, если вам не нужны какие-либо новые функции 2.7, или вам нужно изменить определение плагина с обновленной зависимостью от maven. -фильтр 1.3 (или, может быть, новее).
Я могу убедиться, что такое поведение сохраняется в плагине maven-resources-plugin 3.3.1.
Однако, перейдя по ссылке на проблему Apache, добавленной @mirabilos, я обнаружил более свежий комментарий, который решил для меня проблему. В частности, комментарий Торстена Глейзера от 22 января 22:40 раскрывает его открытие.
Если вы не возражаете против фильтрации, плагин скопирует ваш файл с символической ссылкой, а не символическую ссылку.
Оказывается, есть три разных случая, которые можно применить к каждому каталогу:
<filtering>true</filtering> — here, the symlinks are always followed because the files themselves are possibly manipulated
<filtering>false</filtering> with symlinks followed by default (m-r-p 2.x behaviour)
<filtering>false</filtering> with symlinks copied as-is (m-r-p 3.0/3.1 behaviour)
Итак, пример<resource>
определение может быть:
<resource>
<directory>src/test/resources</directory>
<!-- Enable filtering as workaround for symlink issue: https://issues.apache.org/jira/browse/MRESOURCES-237 -->
<filtering>true</filtering>
<includes>
<include>my_symlinked_file</include>
</includes>
</resource>