Я использую Maven 3.3.3 с Java 8 на Mac Yosemite. У меня многомодульный проект.
<modules>
<module>first-module</module>
<module>my-module</module>
…
</modules>
Когда я создаю один из моих дочерних модулей, например «my-module» сверху, используя «mvn clean install», сборка пытается загрузить артефакты дочернего модуля из удаленного репозитория, который я определил в моем ~ / .m2 /settings.xml файл. Выход ниже
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building my-module 87.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: http://download.java.net/maven/2/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml (788 B at 0.9 KB/sec)
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-20151104.200545-4.pom
Как заставить Maven сначала проверять мой локальный ~ / .m2 / репозиторий перед попыткой загрузки из удаленных репозиториев? Ниже приведены мои удаленные репозитории, определенные в моем файле ~ / .m2 / settings.xml…
<profile>
<id>releases</id>
<activation>
<property>
<name>!releases.off</name>
</property>
</activation>
<repositories>
<repository>
<id>releases</id>
<url>https://my.remoterepository.com/nexus/content/repositories/releases/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
</profile>
<profile>
<id>snapshots</id>
<activation>
<property>
<name>!snapshots.off</name>
</property>
</activation>
<repositories>
<repository>
<id>snapshots</id>
<url>https://my.remoterepository.com/nexus/content/repositories/snapshots/</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
</profile>
Изменить: в ответ на ответ о том, что загрузка происходит, когда артефакта нет, ниже приведен вывод терминала, в котором я доказываю, что файл был в моем репо, но Maven все равно пытается его загрузить ...
Daves-MacBook-Pro-2:my-module davea$ ls -al ~/.m2/repository/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-SNAPSHOT.jar
-rw-r--r-- 1 davea staff 10171 Nov 5 10:22 /Users/davea/.m2/repository/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-SNAPSHOT.jar
Daves-MacBook-Pro-2:my-module davea$ mvn clean install
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.mainco.subco:my-module:jar:87.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-antrun-plugin @ org.mainco.subco:my-module:[unknown-version], /Users/davea/Documents/sb_workspace/my-module/pom.xml, line 678, column 12
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building my-module 87.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: http://download.java.net/maven/2/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml (788 B at 0.8 KB/sec)
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-20151106.043202-8.pom
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first- module-87.0.0-20151106.043202-8.pom (3 KB at 21.9 KB/sec)
Downloading: http://download.java.net/maven/2/org/mainco/subco/subco/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/subco/87.0.0-SNAPSHOT/maven-metadata.xml
settings.xml
(см. Здесь ).Ответы:
У зависимости есть версия моментального снимка. Для моментальных снимков Maven проверит локальный репозиторий, и если артефакт, обнаруженный в локальном репозитории, слишком старый, он попытается найти обновленный в удаленных репозиториях. Вероятно, это то, что вы видите.
Обратите внимание, что это поведение управляется
updatePolicy
директивой в конфигурации репозитория (котораяdaily
по умолчанию используется для репозиториев моментальных снимков).источник
Используйте,
mvn --help
и вы можете увидеть список опций.Есть вариант вроде
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
Таким образом, использование команды
mvn install -nsu
может принудительно скомпилировать с локальным репозиторием.источник
-o
для «автономного» поведения mavenЧтобы по-настоящему заставить maven использовать только ваше локальное репо, вы можете запустить
mvn <goals> -o
. Он-o
сообщает maven, чтобы вы могли работать в автономном режиме, и он останется вне сети.источник
mvn dependency:go-offline
Выполните следующие шаги:
Например, файлы типа .repositories, .pom, .sha1, .lastUpdated и т. Д.
mvn clean install -o
командуЭто поможет использовать jar-файлы локального репозитория вместо подключения к какому-либо репозиторию.
источник
*.repositories
*.sha1
В моем случае у меня был многомодульный проект, как и у вас. Мне пришлось изменить идентификатор группы одной из внешних библиотек, от которой зависел мой проект, как показано ниже.
Из:
<dependencyManagement> <dependency> <groupId>org.thirdparty</groupId> <artifactId>calculation-api</artifactId> <version>2.0</version> <type>jar</type> <scope>provided</scope> </dependency> <dependencyManagement>
Кому:
<dependencyManagement> <dependency> <groupId>org.thirdparty.module</groupId> <artifactId>calculation-api</artifactId> <version>2.0</version> <type>jar</type> <scope>provided</scope> </dependency> <dependencyManagement>
Обратите внимание на раздел <groupId>. Оказалось, что я забыл изменить соответствующий раздел подмодулей, которые определяют эту зависимость в своих файлах pom.
Это сводило меня с ума, потому что модуль был доступен локально.
источник
Параметр -o не сработал для меня, потому что артефакт все еще находится в разработке и еще не загружен, а maven (3.5.x) все еще пытается загрузить его из удаленного репозитория, потому что это первый раз, согласно полученной мной ошибке.
Однако это исправило это для меня: https://maven.apache.org/general.html#importing-jars
После этой ручной установки нет необходимости использовать автономный режим.
ОБНОВИТЬ
Я только что перестроил зависимость, и мне пришлось ее повторно импортировать: обычного
mvn clean install
мне было недостаточноисточник
Даже при рассмотрении всех вышеперечисленных ответов вы все равно можете столкнуться с проблемами, которые завершат автономную сборку maven с ошибкой. В частности, вы можете увидеть следующее предупреждение:
Предупреждение будет немедленно сопровождаться дальнейшими ошибками, и maven прекратит работу.
Для нас самый безопасный способ автономной сборки с автономным кешем maven, созданным в соответствии с приведенными выше советами, - это использовать следующие параметры maven offline:
mvn -o -llr -Dmaven.repo.local=<path_to_your_offline_cache> ...
В частности, опция -llr вас от необходимости настраивать локальный кеш, как предложено в ответе №4.
Также позаботьтесь о том, чтобы параметр localRepository в settings.xml был установлен следующим образом:
<localRepository>${user.home}/.m2/repository</localRepository>
источник
У меня была точно такая же проблема. Бег
mvn clean install
вместо того, чтобыmvn clean compile
решить эту проблему. Разница возникает только при использовании multi-maven-project, поскольку зависимости проекта выгружаются в локальный репозиторий с помощью install.источник
Maven всегда сначала проверяет ваш локальный репозиторий, однако ваша зависимость должна быть установлена в вашем репо, чтобы maven ее нашел.
mvn install
Сначала запустите свой модуль зависимости, а затем создайте свой зависимый модуль.источник