Оригинальный адрес:Приступая к работе с Maven, достаточно прочесть это

адрес блога:tengj.top/

предисловие

Самая яркая звезда на ночном небе, пожалуйста, освети меня, чтобы двигаться вперед в 2018~ Maven используется в нашей повседневной разработке В первый день нового года основные концепции Maven, которые мы видели, разбираются и используются в качестве введение и ссылка.

текст

Концепции Мавена

В качестве инструмента сборки Maven может не только помочь нам автоматизировать сборку, но также абстрагировать процесс сборки и обеспечить реализацию задачи сборки; он кроссплатформенный и предоставляет согласованный внешний интерфейс операций, чего достаточно, чтобы сделать его отличной и популярной сборкой. инструмент.

Maven — это не только инструмент сборки, но и инструмент управления зависимостями и инструмент управления проектами.Он предоставляет центральный репозиторий и может помочь мне автоматически загружать компоненты.

установка мавена

Один: Поскольку я оконная система, я только представляю, как установить его под окном.Перед установкой Maven убедитесь, что JDK установлен.

Два: продолжайОфициальный сайт МавенаЗагрузите интерфейс, чтобы загрузить нужную версию и разархивируйте ее в нужную директорию.

Третье: наконец, установите переменные среды и настройте установку Maven в среде операционной системы, в основном конфигурациюM2_HOME иPATHдва, как показано на рисунке

После того, как все сделано, проверяем, открываем документ и вводим mvn -v Как получить следующую информацию, значит настройка прошла успешно

каталог maven

каталог bin:

Этот каталог содержит сценарии, запускаемые mvn, которые настраивают команды Java, подготавливают путь к классам и связанные системные свойства Java и выполняют команды Java.

загрузочный каталог:

Этот каталог содержит только один файл — plexus-classworlds-2.5.2.jar. plexus-classworlds — это фреймворк загрузчика классов. По сравнению с загрузчиком классов java по умолчанию он предоставляет более богатый синтаксис для облегчения настройки. Maven использует этот фреймворк для загрузки собственной библиотеки классов.

каталог conf:

В этом каталоге находится очень важный файл settings.xml. Непосредственно изменяя файл, поведение Maven можно глобально настроить на машине.В общем, мы предпочитаем копировать файл в каталог ~/.m2/ (~ представляет собой каталог пользователя), а затем изменять файл, чтобы сделать он доступен пользователю Scope настраивает поведение Maven.

каталог библиотеки:

Этот каталог содержит все библиотеки классов Java, необходимые для запуска Maven.Сам Maven разработан в модулях, поэтому пользователи могут видеть такие файлы, как maven-core-3.0.jar, maven-model-3.0.jar и т. д. Он также содержит некоторые сторонние зависимости, используемые Maven, такие как commons-cli-1.2.jar, commons-lang-2.6.jar и т. д.

Описание общей команды Maven

mvn clean: указывает на запуск операции очистки (данные в целевой папке будут очищены по умолчанию).
mvn clean compile: Указывает, что сначала нужно запустить очистку, а затем компиляцию, после чего код будет скомпилирован в целевую папку.
mvn clean test: запустить очистку и тесты.
mvn clean package: Выполнить очистку и упаковку.
mvn clean install: запустите clean and install, который установит упакованный пакет в локальный репозиторий, чтобы другие проекты могли его вызывать.
mvn clean deploy: выполнить очистку и опубликовать (опубликовать на частном сервере).

Большинство вышеперечисленных команд написаны последовательно, и вы также можете разделить и выполнить их по отдельности. Это в реальном времени, в зависимости от личных предпочтений и требований к использованию. Eclipse Run as предоставит общие команды для проектов maven.

установить http-прокси

Отредактируйте файл see.xml Иногда ваша компания по соображениям безопасности требует, чтобы вы использовали аутентифицированный прокси-сервер для доступа в Интернет. В этом случае нужно настроить HTTP-прокси для Maven, чтобы он мог нормально обращаться к внешнему репозиторию для загрузки необходимых ресурсов. Сначала убедитесь, что вы не можете получить прямой доступ к общедоступному центральному репозиторию maven, и запустите команду ping repo1.maven.org напрямую, чтобы проверить сеть. Если вам действительно нужен прокси, сначала проверьте, не разблокирован ли прокси-сервер. Например, сейчас есть прокси-сервис с IP-адресом 218.14.227.197 и портом 3128, мы можем запустить telnet 218.14.227.197 3128, чтобы проверить, разблокирован ли порт этого адреса. Если вы получили сообщение об ошибке, вам необходимо сначала получить правильную информацию о прокси-сервисе.Если соединение telnet правильное, введите ctrl+], затем q, нажмите Enter и выйдите.

После проверки отредактируйте файл ~/.m2/settings.xml (или скопируйте $M2_HOME/conf/settings.xml, если он не существует). Добавьте конфигурацию прокси следующим образом:

<settings>  
  ...  
  <proxies>  
    <proxy>  
      <id>my-proxy</id>  
      <active>true</active>  
      <protocol>http</protocol>  
      <host>218.14.227.197</host>  
      <port>3128</port>  
      <!--  
        <username>***</username>  
        <password>***</password>  
        <nonProxyHosts>  
          repository.mycom.com|*.google.com  
        </nonProxyHosts>  
      -->  
    </proxy>  
  </proxies>  
  ...  
</settings>

Эта конфигурация очень проста, под прокси может быть несколько прокси-элементов, если заявлено несколько прокси-элементов, по умолчанию будет работать первый активированный прокси. Здесь объявляется прокси с идентификатором my-proxy. Значение active равно true для активации прокси. Protocol представляет используемый протокол прокси, здесь http. Конечно, самое главное — правильно указать имя хоста (элемент host) и порт (элемент port). Имя пользователя, пароль и элементы nonProxyHosts закомментированы в приведенной выше конфигурации xml. Когда прокси-сервис требует аутентификации, необходимо настроить имя пользователя и пароль. Элемент nonProxyHost используется, чтобы указать, какие хосты не нуждаются в прокси.Вы можете использовать символ «|», чтобы разделить несколько имен хостов. Кроме того, эта конфигурация также поддерживает подстановочные знаки, такие как: *.google.com означает, что все доменные имена, заканчивающиеся на google.com, не должны проходить через прокси-сервер.

Установка плагина Maven на основе IDEA

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

Maven использует

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.tengj</groupId>
    <artifactId>springBootDemo1</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>springBootDemo1</name>
</project>

Первая строка кода — это заголовок XML, указывающий версию и кодировку XML-документа. project является корневым элементом всех pom.xml, он также объявляет некоторые связанные с POM пространства имен и элементы xsd. Первый дочерний элемент modelVersion под корневым элементом указывает версию текущей модели POM, для Maven3 это может быть только 4.0.0. Самое главное в коде — включить groupId, ArtiftId и версию. Эти три элемента определяют основные координаты проекта.В мире Maven любой jar, pom или jar различается на основе этих основных координат.

groupId определяет, к какой группе принадлежит проект, и может называться произвольно. Например, проект Google myapp называется com.google.myapp.

ArtiftId определяет уникальный идентификатор текущего проекта Maven в группе, например определение hello-world.

version указывает текущую версию проекта 0.0.1-SNAPSHOT, SNAPSHOT означает моментальный снимок, указывающий на то, что проект все еще находится в стадии разработки и нестабилен.

Элемент name имеет имя проекта, которое более удобно для пользователя.Хотя это не требуется, рекомендуется объявить имя для каждого POM, чтобы облегчить обмен информацией

Зависимая конфигурация

<project>
...
<dependencies>
    <dependency>
        <groupId>实际项目</groupId>
　　　　 <artifactId>模块</artifactId>
　　　　 <version>版本</version>
　　　　 <type>依赖类型</type>
　　　　 <scope>依赖范围</scope>
　　　　 <optional>依赖是否可选</optional>
　　　　 <!—主要用于排除传递性依赖-->
　　　　 <exclusions>
　　　　     <exclusion>
　　　　　　　    <groupId>…</groupId>
　　　　　　　　　 <artifactId>…</artifactId>
　　　　　　　</exclusion>
　　　　 </exclusions>
　　</dependency>
<dependencies>
...
</project>

Зависимости в проекте корневого элемента могут содержать один или несколько элементов зависимости для объявления одной или нескольких зависимостей проекта. Элементы, которые может содержать каждая зависимость:

идентификатор группы, идентификатор артефакта и версия: Так как базовые координаты, то для любой зависимости базовые координаты самые важные, и Maven может найти нужные зависимости по координатам.
type: Тип зависимости для упаковки, определяемой координатами элемента. В большинстве случаев этот элемент не нужно объявлять, его значение по умолчанию — jar.
scope: Объем зависимостей
optional: отметить, является ли зависимость необязательной
exclusions: используется для исключения транзитивных зависимостей

Область зависимости

Область зависимости используется для управления отношениями между зависимостями и тремя путями к классам (путь к классам компиляции, путь к классам тестирования и путь к классам запуска).Maven имеет следующие области зависимостей:

**compile:** скомпилировать область зависимостей. Если не указано, область зависимости будет использоваться по умолчанию. Зависимости Maven, использующие эту область зависимостей, действительны для всех трех путей к классам: compile, test и run. Типичный пример — spring-code, который нужно использовать при компиляции, тестировании и запуске.
test:Тестовая область зависимости. Зависимости Maven, использующие вторичную область зависимостей, действительны только для тестового пути к классам и будут недоступны при компиляции основного кода или запуске проекта. Типичным примером является Jnuit, который нужен только при компиляции тестового кода и запуске тестов.
**предоставлено:** предоставлена область зависимости. Зависимости Maven, использующие эту область зависимостей, действительны для путей к классам компиляции и тестирования, но не во время выполнения. Типичный пример — servlet-api, эта зависимость требуется при компиляции и тестировании проекта, но при запуске проекта из-за контейнера и обеспечения Maven не нужно повторно вводить ее.
**среда выполнения:** область зависимости времени выполнения. Зависимости Maven, использующие эту область зависимостей, допустимы для тестирования и выполнения в пути к классам, но не при компиляции основного кода. Типичным примером является реализация драйвера JDBC.Для компиляции основного кода проекта требуется только интерфейс JDBC, предоставляемый JDK, а специальный драйвер JDBC, реализующий указанный выше интерфейс, требуется только при выполнении тестов или запуске проекта.
**система:** область зависимости системы. Связь между этой зависимостью и тремя путями к классам точно такая же, как и в предоставленной области зависимости.Однако при использовании зависимости с системной областью необходимо явно указать путь к зависимому файлу через элемент systemPath. Поскольку такие зависимости не разрешаются через репозитории Maven и часто привязаны к собственной системе, что может представлять собой непереносимые сборки, их следует использовать с осторожностью. Элемент systemPath может ссылаться на переменные среды, такие как:

<dependency>
    <groupId>javax.sql</groupId>
    <artifactId>jdbc-stdext</artifactId>
    <Version>2.0</Version>
    <scope>system</scope>
    <systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>

**import:** Импорт области зависимостей. Объем этой зависимости фактически не влияет на три пути к классам.

Отношения между вышеупомянутыми различными областями зависимостей, кроме импорта, и тремя путями к классам, следующие:

транзитивная зависимость

Возьмем в качестве примера проект электронной почты учетной записи, учетная запись электронной почты имеет зависимость от Spring-кода области компиляции, а Spring-код имеет зависимость от Commons-Logging области компиляции, тогда Commons-Logging станет зависимостью области компиляции учетной записи. -email , commons-logging является транзитивной зависимостью от account-email

Благодаря механизму транзитивных зависимостей при использовании Spring Framework вам не нужно думать о том, от чего это зависит, и вам не нужно беспокоиться о введении избыточных зависимостей. Maven проанализирует POM каждой прямой зависимости и введет эти необходимые косвенные зависимости в текущий проект в виде транзитивных зависимостей.

Область зависимости

Предполагая, что А зависит от В, а В зависит от С, мы говорим, что А имеет первую прямую зависимость от В, В имеет вторую прямую зависимость от С и А имеет транзитивную зависимость от С. Область действия первой прямой зависимости и второй прямой зависимости определяет область действия транзитивной зависимости, как показано на следующем рисунке: крайняя левая строка представляет область действия первой прямой зависимости, верхняя строка представляет область действия второй прямой зависимости, а крест ячейка в середине Представляет транзитивную область зависимости.

Из приведенного выше рисунка мы можем найти следующие правила:

Когда областью действия второй прямой зависимости является компиляция, область действия транзитивной зависимости совпадает с областью действия первой прямой зависимости;
Когда область второй прямой зависимости является тестовой, зависимость не будет передана;
Когда предоставляется область второй прямой зависимости, передаются только те зависимости, для которых также предоставляется область действия первой прямой зависимости, а также предоставляется область действия всех транзитивных зависимостей;
Когда областью действия второй прямой зависимости является время выполнения, область действия транзитивной зависимости совпадает с областью действия первой прямой зависимости, за исключением столбца компиляции, областью действия транзитивной зависимости является время выполнения.

## Посредничество зависимостей Иногда, когда транзитивная зависимость вызывает проблему, необходимо четко знать, из какого пути импортируется транзитивная зависимость. В этом состоит роль посредничества. Существует два основных принципа использования посредничества: 1. Предпочтительнее ближайший путь Например, в проекте есть A с такими зависимостями: A->B->C->X(1.0), A->D->X(2.0), X — транзитивная зависимость от A, но есть две зависимости от две версии X, поэтому по первому принципу путь A->D->X(2.0) короткий, поэтому X(2.0) будет проанализирован и использован 2. Первый декларант имеет преимущество Если все пути имеют одинаковую длину, первый принцип не будет работать, например, пути A->B->Y(1.0), A->C->Y(2.0), Y(1.0) и Y (2.0) одинаковы, Итак, в это время, согласно второму принципу, разбирается первое объявление.

## Необязательные зависимости

Как показано на рисунке, в проекте A зависит от B, а B зависит от X и Y. Если все три области компиляции, то X и Y являются транзитивными зависимостями области компиляции A, но если я хочу X, Y не Как транзитивная зависимость А, она им не используется. Дополнительные зависимости конфигурации, упомянутые ниже, являются обязательными.

<project>  
    <modelVersion>4.0.0</modelVersion>  
    <groupId>com.juvenxu.mvnbook</groupId>  
    <artifactId>project-b</artifactId>  
    <version>1.0.0</version>  
    <dependencies>  
        <dependency>  
            <groupId>mysql</groupId>  
            <artifactId>mysql-connector-java</artifactId>  
            <version>5.1.10</version>  
            <optional>true</optional>  
        </dependency>  
        <dependency>  
            <groupId>postgresql</groupId>  
            <artifactId>postgresql</groupId>  
            <version>8.4-701.jdbc3</version>  
            <optional>true</optional>  
        </dependency>  
    </dependencies>  
</project>

Конфигурация тоже простая, добавляем зависимости

<optional>true</optional>

Это означает необязательные зависимости, поэтому, если A хочет использовать X, Y, он напрямую добавит зависимости.

исключить зависимости

Иногда вводимые вами зависимости содержат ненужные вам зависимости, и вы хотите импортировать то, что хотите. В этом случае вам необходимо исключить зависимости. Например, spring-boot-starter-web на рисунке ниже поставляется с логбэком. package, я хочу импортировать log4j2, поэтому я сначала исключаю пакет зависимостей logback, а затем импортирую нужный пакет.

Исключить зависимую структуру кода:

<exclusions>
    <exclusion>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-logging</artifactId>
    </exclusion>
</exclusions>

Обратите внимание: при объявлении исключения необходимы только groupId и артефакты, а не элементы версии, потому что только groupId и артефакты необходимы для однозначного определения зависимости в графе зависимостей.

Зависимость от категоризации

Иногда многие зависимые пакеты, которые мы вводим, поступают из разных модулей одного и того же проекта, поэтому их номера версий одинаковы.В настоящее время мы можем использовать атрибуты для унифицированного управления номерами версий.

<project>  
    <modelVersion>4.0.0</modelVersion>  
    <groupId>com.juven.mvnbook.account</groupId>  
    <artifactId>accout-email</artifactId>  
    <version>1.0.0-SNAPSHOT</version>  
    <properties>  
        <springframework.version>1.5.6</springframework.version>  
    </properties>  
    <dependencies>  
        <dependency>  
            <groupId>org.springframework</groupId>  
            <artifactId>spring-core</artifactId>  
            <version>${springframework.version}</version>  
        </dependency>   
        <dependency>  
            <groupId>org.springframework</groupId>  
            <artifactId>spring-beans</artifactId>  
            <version>${springframework.version}</version>  
        </dependency>         
    </dependencies>  
</project>

Как показано на рисунке, сначала

</properties>
    这里定义你先要的版本
</properties>

для определения, затем используйте ${} для импорта ваших свойств ниже зависимости.

склад

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

Происхождение склада

В мире Maven любая зависимость, плагин или результат сборки проекта можно назвать артефактом. Благодаря механизму координат любой проект Maven использует любой артефакт абсолютно одинаково. Исходя из этого, Maven может хранить компоненты, совместно используемые всеми проектами Maven, в едином месте, которое называется складом.

Фактический проект Maven больше не будет хранить свои зависимости, им нужно только объявить эти зависимые координаты, когда это необходимо (например, при компиляции проекта нужно добавить зависимости в путь к классам), Maven автоматически найдет склад в соответствии с согласовывать компоненты и использовать их.

Чтобы добиться повторного использования, компоненты, которые могут быть созданы после сборки проекта, также могут быть установлены или развернуты в хранилище для использования в других проектах.

схема склада

У любого компонента есть свои уникальные координаты, по которым может быть определен уникальный путь хранения на складе, который представляет собой макет склада Maven. Соответствующая связь между путем и координатами: groupId/artifactId/version/artifactId-version.packaging. Например, следующий подключаемый модуль подкачки зависит от следующего:

<dependency>
      <groupId>com.github.pagehelper</groupId>
      <artifactId>pagehelper-spring-boot-starter</artifactId>
      <version>1.1.0</version>
</dependency>

Тогда путь его соответствующего склада такой:

Хранилище Maven хранится на основе простой файловой системы, и мы также понимаем его способ хранения, поэтому при возникновении каких-либо проблем, связанных с хранилищем, очень удобно найти нужные файлы и локализовать проблему.

Классификация складов

местный склад

Вообще говоря, в каталоге проекта Maven нет такого каталога, как lib/ для хранения файлов зависимостей. Когда Maven компилирует или тестирует, если ему нужно использовать файл зависимостей, он всегда использует файл зависимостей из локального репозитория на основе координат.

По умолчанию, независимо от того, в Windows или Linux, у каждого пользователя есть каталог репозитория с именем .m2/repository/ в его собственном пользовательском каталоге. Если вы хотите настроить адрес каталога локального репозитория. Вы можете отредактировать файл ~/.m2/settings.xml и установить значение элемента localRepository на нужный адрес репозитория, например:

<settings>
<localRepository>D:\java\repository\</localRepository>
</settings>

Таким образом, адрес локального репозитория пользователя устанавливается в D:\java\repository\. Следует отметить, что по умолчанию файл ~/.m2/settings.xml не существует, и пользователю необходимо скопировать файл $M2_HOME/conf/settings.xml из каталога установки Maven и отредактировать его.

Удаленный склад - Центральный склад

Поскольку исходный локальный репозиторий пуст, Maven должен знать хотя бы один доступный удаленный репозиторий, чтобы загружать необходимые артефакты при выполнении команды Maven. Центральное хранилище является таким удаленным хранилищем по умолчанию.Установочный файл Maven поставляется с конфигурацией центрального хранилища.

Центральный репозиторий содержит самые популярные в мире компоненты Java с открытым исходным кодом, а также исходный код, информацию об авторах, SCM, информацию, информацию о лицензиях и т. д. Ежемесячно его посещают около 100 миллионов программистов Java со всего мира. для разработчиков Java в мире можно увидеть.

Удаленный склад - частный сервер

Частный сервер — это специальное удаленное хранилище, служба хранилища, настроенная в локальной сети, которая выступает в качестве удаленного хранилища в глобальной сети для пользователей Maven в локальной сети. Когда Maven необходимо загрузить компонент, он запрашивает его с частного сервера.Если компонент не существует на частном сервере, он будет загружен из внешнего удаленного репозитория, кэширован на частном сервере, а затем обслужит запрос на загрузку Maven. Таким образом, некоторые компоненты, которые нельзя загрузить из внешних репозиториев, также могут быть загружены локально на частный сервер для всеобщего использования. Преимущества частных серверов:

Сохранить собственную скорость интернета
Ускорение сборки Maven
Развертывание сторонних сборок
Улучшите стабильность, улучшите контроль
Снизить нагрузку на центральный склад

Конфигурация удаленного репозитория

В обычной разработке мы часто не используем центральное хранилище по умолчанию.Скорость доступа к центральному хранилищу по умолчанию относительно низкая, и к нему может обращаться много людей, и иногда оно не может удовлетворить потребности нашего проекта.Некоторые компоненты, необходимые для проект может располагаться централизованно, не в репозитории, а в других удаленных репозиториях, таких как репозиторий JBoss Maven. В это время склад можно настроить в pom.xml, код такой:

<!-- 配置远程仓库 -->
    <repositories>
        <repository>
            <id>jboss</id>
            <name>JBoss Repository</name>
            <url>http://repository.jboss.com/maven2/</url>
            <releases>
                <enabled>true</enabled>
                <updatePolicy>daily</updatePolicy>
            </releases>
            <snapshots>
                <enabled>false</enabled>
                <checksumPolicy>warn</checksumPolicy>
            </snapshots>
            <layout>default</layout>
        </repository>
    </repositories>

**репозиторий:** в элементе репозиториев можно объявить один или несколько удаленных репозиториев с помощью подэлемента репозиторий.
**id:** Уникальный идентификатор декларации склада. Следует особо отметить, что идентификатор, используемый центральным складом, поставляемым с Maven, является центральным. Если другие декларации склада также используют этот идентификатор, конфигурация центрального склада будет перезаписан.
**name: **Название склада, дайте нам знать, какой склад интуитивно понятен и удобен, и мы пока не нашли других замечательных значений.
**url:** указывает на адрес склада. Вообще говоря, адрес основан на протоколе http. Пользователи Maven могут открыть адрес склада в браузере для просмотра компонентов.
релизы и снимки:Maven используется для контроля разрешений для загрузки компонента выпуска и членов снимков. должен быть в курсеenabledВложенный элемент, в этом примере включенное значение выпусков равно true, что означает, что поддержка загрузки выпускной версии репозитория JBoss включена, а включенное значение моментальных снимков равно false, что означает, что поддержка загрузки версии моментального снимка репозитория JBoss отключен. В этой конфигурации Maven будет загружать только артефакты выпуска из репозитория JBoss, а не артефакты моментальных снимков.
**layout:** значение элемента по умолчанию указывает, что макет хранилища является макетом по умолчанию Maven2 и Maven3, а не макетом Maven1. Макет Maven1 в основном не используется.
**Другое:** Для выпусков и моментальных снимков, помимо включенного, они также содержат два других подэлемента updatePolicy и checksumPolicy.

1: элементupdatePolicyИспользуется для настройки того, как часто Maven проверяет наличие обновлений из удаленных репозиториев.Значение по умолчанию — ежедневно, что означает, что Maven проверяет обновления один раз в день. Другие доступные значения включают: never — никогда не проверять наличие обновлений; always — проверять наличие обновлений при каждой сборке; interval: X — проверять наличие обновлений каждые X минут (X — произвольное целое число).
2: ЭлементыchecksumPolicyСтратегия, используемая для настройки Maven для проверки файлов контрольной суммы. Когда сборка развертывается в репозиторий Maven, также развертываются соответствующие файлы контрольной суммы. При загрузке артефактов Maven проверит файл контрольной суммы.Если проверка контрольной суммы не удалась, когда значением checksumPolicy является предупреждение по умолчанию, Maven выведет предупреждающее сообщение при выполнении сборки.Другие доступные значения включают: fail-Maven Fail the строить на ошибках контрольной суммы; игнорировать — заставляет Maven полностью игнорировать ошибки контрольной суммы.

Аутентификация для удаленных репозиториев

Большинство удаленных репозиториев не требуют проверки подлинности, но если вы используете их внутри, вам все равно необходимо настроить информацию для проверки подлинности по соображениям безопасности. Настройка аутентификационных данных отличается от настройки удаленных хранилищ.Удаленные склады можно настроить непосредственно в файле pom.xml, но аутентификационные данные необходимо настроить в файле settings.xml. Это связано с тем, что pom часто отправляется в репозиторий кода для доступа всех участников, а settings.xml обычно существует только локально. Поэтому более безопасно настраивать информацию для аутентификации в settings.xml.

<settings>
 2     ...
 3     <!--配置远程仓库认证信息-->
 4     <servers>
 5         <server>
 6             <id>releases</id>
 7             <username>admin</username>
 8             <password>admin123</password>
 9         </server>
10     </servers>
11     ...
12 </settings>

В дополнение к настройке пароля учетной записи значением ключа здесь является идентификатор.Этот идентификатор должен совпадать с идентификатором репозитория удаленного репозитория, настроенного в pom.xml.Именно этот идентификатор связывает информацию аутентификации с конфигурацией репозитория.

Развертывание артефактов в удаленных репозиториях

Цель построения собственного удаленного склада — облегчить развертывание компонентов собственного проекта и некоторых компонентов, которые нельзя получить напрямую с внешних складов. Таким образом, его могут использовать другие члены команды во время разработки. Помимо компиляции, тестирования и упаковки проектов, Maven также может развертывать артефакты, созданные проектами, на удаленных складах. Во-первых, необходимо отредактировать файл проекта pom.xml. Настройте элемент DistributionManagement, код выглядит следующим образом:

<distributionManagement>
        <repository>
            <id>releases</id>
            <name>public</name>
            <url>http://59.50.95.66:8081/nexus/content/repositories/releases</url>
        </repository>
        <snapshotRepository>
            <id>snapshots</id>
            <name>Snapshots</name>
            <url>http://59.50.95.66:8081/nexus/content/repositories/snapshots</url>
        </snapshotRepository>
</distributionManagement>

Глядя на код, вы можете увидеть разницу в наименовании: Repository представляет собой репозиторий компонента версии выпуска (стабильной версии), а snapshotRepository представляет собой репозиторий версии моментального снимка (версии разработки и тестирования). Оба элемента должны быть настроены с идентификатором, именем и URL-адресом, идентификатор является уникальным идентификатором удаленного склада, имя для удобства чтения человеком, а URL-адрес ключа представляет собой адрес склада.

После завершения настройки запустите команду mvn clean deploy, и Maven развернет компоненты, выводимые сборкой проекта, на удаленное хранилище, соответствующее конфигурации.Если текущая версия проекта является версией моментального снимка, она будет развернута на адрес хранилища версии моментального снимка, в противном случае она будет развернута в релизе Адрес репозитория версии. Значение true определяет, является ли текущий проект моментальным снимком или версией выпуска. Забытые студенты смотрят на конфигурацию удаленного склада ## выше.

зеркало

Если репозиторий X может предоставить все, что хранится в репозитории Y, то X можно считать зеркалом Y. Любой, кто использовал Maven, знает, что зарубежные центральные склады слишком медленны в использовании, поэтому необходимо выбрать отечественное зеркало, я рекомендую отечественное зеркало Alibaba Cloud. Alibaba Cloud Mirror: конфигурация очень проста.Измените файл settings.xml в папке conf и добавьте следующую конфигурацию зеркала:

<mirrors>
    <mirror>
      <id>alimaven</id>
      <name>aliyun maven</name>
      <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
      <mirrorOf>central</mirrorOf>        
    </mirror>
  </mirrors>

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

Представьте здесь<mirrorOf>Различные варианты конфигурации

<mirrorOf>*<mirrorOf>: соответствует всем удаленным репозиториям.
<mirrorOf>external:*<mirrorOf>: соответствует всем удаленным репозиториям, кроме тех, которые используют localhost и те, которые используют протокол file://. То есть сопоставить все удаленные репозитории, которых нет на локальной машине.
<mirrorOf>repo1,repo2<mirrorOf>: Сопоставьте repo1h и repo2, используйте запятые для разделения нескольких удаленных репозиториев.
<mirrorOf>*,!repo1<mirrorOf>: соответствует всем удаленным репозиториям, кроме repo1, используйте восклицательный знак, чтобы исключить репозитории из сопоставления.

Следует отметить, что, поскольку зеркальный склад полностью экранирует зеркальный склад, когда зеркальный склад работает нестабильно или прекращает обслуживание, Maven все равно не сможет получить доступ к зеркальному складу, а значит, не сможет загрузить компоненты.

Складские услуги Поиск

Вот 2 адреса, которые обеспечивают поиск складских услуг:

Сонатип Нексус:repository.sonatype.org/
MVN-репозиторий:mvnrepository.com/

Суммировать

Это пока так, и я продолжу дополнять и обновлять эту статью позже, отдельное введение будет сделано о построении приватных серверов. Эта статья основана на доработке и доработке "Битвы Maven". Если вам нужна электронная книга, вы можете подписаться на публичный аккаунт блоггера в WeChat: Du Ye Java Super Seminary (java2Learn) answer keywordsmavenПолучить электронную книгу.