Локальные банки не включены в путь класса (` <scope> system</scope>`)

Ответ 1

С областью "system", ожидается, что контейнер предоставит артефакт. Из maven docs:

при условии

Это очень похоже на компиляцию, но указывает, что вы ожидаете, что JDK или контейнера, чтобы обеспечить зависимость от во время выполнения. Например, при создании веб-приложение для Java Enterprise Edition, вы должны установить зависимости от API Servlet и связанных API Java EE с предоставленной областью потому что веб-контейнер обеспечивает эти классы. Этот объем доступны для компиляции и тестирования classpath, и не является транзитивным.

[...]

система

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

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

Цель install: install-file может быть использована для установки одного файла (без POM) в ваш локальный репозиторий. После этого измените тип зависимостей на "компиляцию" и удалите элемент "systemPath".

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

Ответ 2

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

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

Собственно, я написал много раз (здесь, здесь, здесь и здесь), что следует избегать зависимостей system. Они больше всего вредны, люди злоупотребляют ими, и они порождают почти всегда больше неприятностей, чем пользы.

Позвольте мне процитировать мини-руководство по зависимостям, если вы хотите "официальную" точку зрения:

• system. Эта зависимость требуется на определенной стадии жизненного цикла вашего проекта, но зависит от системы. Использование этой области не рекомендуется: это считается "расширенной" функцией, и ее следует использовать только тогда, когда вы действительно понимаете все последствия ее использования, которые могут быть чрезвычайно сложными, если на самом деле невозможно количественно определить. Этот объем по определению делает вашу сборку не переносной. Это может быть необходимо в некоторых случаях. Область системы включает элемент <systemPath>, который указывает на физическое расположение этой зависимости на локальном компьютере. Таким образом, он используется для обозначения какого-либо артефакта, ожидаемого на данном локальном компьютере, а не в репозитории; и путь которого может изменяться от машины к машине. Элемент systemPath может ссылаться на переменные среды по своему пути: ${JAVA_HOME} например.

Итак, вместо использования области system либо:

• Добавьте свои библиотеки в локальный репозиторий через install:install-file. Это быстрый и грязный способ заставить все работать, это может быть вариант, если вы один, но он делает вашу сборку не переносной.
• Установите и запустите "корпоративный репозиторий", например Nexus, Archiva или Artifactory, и добавьте свои библиотеки через deploy:deploy-file. Это сценарий идеальный.
• Установите репозиторий на основе файлов, как описано в этом предыдущем ответе, и разместите там свои библиотеки. Это лучший компромисс, если у вас нет корпоративного репозитория, но вам нужно работать в команде и не хотите жертвовать переносимостью.

Пожалуйста, прекратите использование области system.

Ответ 3

Попробуйте установить банки в локальный репозиторий. Это когда время сборки не должно быть разницы между вашими локальными банками и банками в больших хранилищах.

Ответ 4

Просто то, что попало мне в глаза: На пути вы используете обычные косые черты unix. Windows использует обратную косую черту для путей:. Я не знаю, сможет ли maven преобразовать их друг в друга, поэтому, возможно, попробуйте ввести путь следующим образом:

C:\гелькапы\Lib\zipdiff-0.4.jar

Ответ 5

Не пробовав это раньше, чтобы он не работал, можете ли вы изменить область для компиляции?

<dependency>
   <groupId>sourceforge.net</groupId>
   <artifactId>zipdiff</artifactId>
   <version>0.4</version>
   <scope>compile</scope>
   <systemPath>C:/gelcap/lib/zipdiff-0.4.jar</systemPath>
</dependency>