Руководство по POM (Project Object Model) в Maven
POM (Project Object Model) является основой любого Maven-проекта. Файл pom.xml определяет структуру проекта, его зависимости, процесс сборки и другие аспекты, необходимые для управления жизненным циклом проекта. Этот документ представляет собой XML-файл, который Maven интерпретирует для создания модели проекта в памяти.
Основные теги
Основные теги pom.xml формируют базовую идентификацию и структуру проекта. Они обязательны или критически важны для корректной работы Maven.
<project>: Корневой элемент каждого pom.xml. Он определяет пространство имен XML (xmlns) и схему (xsi:schemaLocation), чтобы Maven мог валидировать файл. Все остальные элементы являются дочерними для <project>. В памяти Maven создает объект Project, который хранит всю информацию о проекте, включая зависимости, плагины и настройки сборки.
<modelVersion>: Указывает версию модели POM, используемой в файле. На момент 2025 года стандартной является версия 4.0.0. Этот тег необходим, так как Maven использует его для определения правил парсинга и совместимости. Неправильная версия приведет к ошибке парсинга.
<groupId>: Уникальный идентификатор группы, к которой относится проект. Обычно это доменное имя компании или организации в обратном порядке (например, com.example). В памяти Maven использует groupId как часть координат для идентификации артефакта в репозитории.
<artifactId>: Уникальное имя артефакта внутри группы. Это название проекта или модуля (например, my-app). Вместе с groupId и version формирует уникальные координаты артефакта.
<version>: Версия проекта. Следует семантическому версионированию (например, 1.0.0-SNAPSHOT). Maven использует версию для управления артефактами в локальном и удаленных репозиториях. Суффикс SNAPSHOT указывает на нестабильную версию, что влияет на поведение кэширования.
<packaging>: Определяет тип выходного артефакта (например, jar, war, pom). По умолчанию — jar. Этот тег влияет на жизненный цикл сборки, так как Maven выбирает соответствующие плагины и цели (goals) для обработки. Например, для war подключается плагин maven-war-plugin.
Эти теги формируют минимальный pom.xml. Maven парсит их в объектную модель, которая хранится в памяти JVM во время выполнения. Объектная модель включает org.apache.maven.model.Model, где каждый тег маппится на соответствующее поле или коллекцию. Например, groupId, artifactId и version объединяются в уникальный ключ артефакта.
Расширенные теги
Расширенные теги добавляют метаданные, улучшающие документацию и управление проектом. Они необязательны, но полезны в корпоративных средах.
<name>: Человекочитаемое название проекта. Используется в отчетах и документации, генерируемых Maven (например, через maven-site-plugin). Не влияет на логику сборки, но хранится в метаданных артефакта.
<description>: Описание проекта. Как и <name>, используется для документации. Maven включает это поле в метаданные артефакта, которые публикуются в репозиторий.
<url>: URL проекта, например, сайт или репозиторий. Используется в документации и для генерации ссылок в отчетах.
<inceptionYear>: Год создания проекта. Это поле чисто информационное, хранится в метаданных.
<organization>: Содержит информацию об организации, включая <name> и <url>. Используется для единообразной документации в крупных проектах.
Эти теги не влияют на процесс сборки, но добавляются в файл метаданных артефакта (META-INF/maven/groupId/artifactId/pom.properties), который создается при упаковке. В памяти они хранятся как часть объекта Model, но не участвуют в логике выполнения.
#Java #middle #Maven #pom
POM (Project Object Model) является основой любого Maven-проекта. Файл pom.xml определяет структуру проекта, его зависимости, процесс сборки и другие аспекты, необходимые для управления жизненным циклом проекта. Этот документ представляет собой XML-файл, который Maven интерпретирует для создания модели проекта в памяти.
Основные теги
Основные теги pom.xml формируют базовую идентификацию и структуру проекта. Они обязательны или критически важны для корректной работы Maven.
<project>: Корневой элемент каждого pom.xml. Он определяет пространство имен XML (xmlns) и схему (xsi:schemaLocation), чтобы Maven мог валидировать файл. Все остальные элементы являются дочерними для <project>. В памяти Maven создает объект Project, который хранит всю информацию о проекте, включая зависимости, плагины и настройки сборки.
<modelVersion>: Указывает версию модели POM, используемой в файле. На момент 2025 года стандартной является версия 4.0.0. Этот тег необходим, так как Maven использует его для определения правил парсинга и совместимости. Неправильная версия приведет к ошибке парсинга.
<groupId>: Уникальный идентификатор группы, к которой относится проект. Обычно это доменное имя компании или организации в обратном порядке (например, com.example). В памяти Maven использует groupId как часть координат для идентификации артефакта в репозитории.
<artifactId>: Уникальное имя артефакта внутри группы. Это название проекта или модуля (например, my-app). Вместе с groupId и version формирует уникальные координаты артефакта.
<version>: Версия проекта. Следует семантическому версионированию (например, 1.0.0-SNAPSHOT). Maven использует версию для управления артефактами в локальном и удаленных репозиториях. Суффикс SNAPSHOT указывает на нестабильную версию, что влияет на поведение кэширования.
<packaging>: Определяет тип выходного артефакта (например, jar, war, pom). По умолчанию — jar. Этот тег влияет на жизненный цикл сборки, так как Maven выбирает соответствующие плагины и цели (goals) для обработки. Например, для war подключается плагин maven-war-plugin.
Эти теги формируют минимальный pom.xml. Maven парсит их в объектную модель, которая хранится в памяти JVM во время выполнения. Объектная модель включает org.apache.maven.model.Model, где каждый тег маппится на соответствующее поле или коллекцию. Например, groupId, artifactId и version объединяются в уникальный ключ артефакта.
Расширенные теги
Расширенные теги добавляют метаданные, улучшающие документацию и управление проектом. Они необязательны, но полезны в корпоративных средах.
<name>: Человекочитаемое название проекта. Используется в отчетах и документации, генерируемых Maven (например, через maven-site-plugin). Не влияет на логику сборки, но хранится в метаданных артефакта.
<description>: Описание проекта. Как и <name>, используется для документации. Maven включает это поле в метаданные артефакта, которые публикуются в репозиторий.
<url>: URL проекта, например, сайт или репозиторий. Используется в документации и для генерации ссылок в отчетах.
<inceptionYear>: Год создания проекта. Это поле чисто информационное, хранится в метаданных.
<organization>: Содержит информацию об организации, включая <name> и <url>. Используется для единообразной документации в крупных проектах.
Эти теги не влияют на процесс сборки, но добавляются в файл метаданных артефакта (META-INF/maven/groupId/artifactId/pom.properties), который создается при упаковке. В памяти они хранятся как часть объекта Model, но не участвуют в логике выполнения.
#Java #middle #Maven #pom
Работа с <properties>
Тег <properties> позволяет определять пользовательские переменные, которые можно использовать в других частях pom.xml. Это улучшает читаемость и упрощает управление конфигурацией.
Пример:
Переменные используются через синтаксис ${property.name}.
Например:
Maven при парсинге pom.xml заменяет все ${...} на соответствующие значения. Это происходит на этапе создания модели в памяти. Если свойство не найдено, Maven пытается использовать системные свойства JVM или переменные окружения. Если и это не удается, сборка завершится ошибкой.
Свойства также могут быть переопределены через командную строку:
В памяти свойства хранятся в объекте Properties внутри модели Model. Они доступны всем плагинам и процессам сборки.
Важный нюанс: свойства не наследуются автоматически в дочерних модулях, если они определены в <properties> родительского POM. Для этого нужно использовать <dependencyManagement> или <pluginManagement>.
<dependencies>: Управление зависимостями
Тег <dependencies> определяет библиотеки, необходимые проекту. Каждая зависимость описывается тегом <dependency> с обязательными полями groupId, artifactId и version.
Scope'ы зависимостей
Атрибут <scope> определяет область применения зависимости:
compile: Зависимость доступна для компиляции, тестирования и выполнения. Включается в итоговый артефакт (например, в jar). Это значение по умолчанию.
provided: Зависимость нужна для компиляции, но предоставляется средой выполнения (например, сервлет API в контейнере). Не включается в итоговый артефакт.
runtime: Зависимость нужна только во время выполнения (например, JDBC-драйвер). Не используется при компиляции.
test: Зависимость нужна только для тестирования (например, JUnit). Не включается в итоговый артефакт.
system: Указывает локальный путь к зависимости через <systemPath>. Используется редко, так как нарушает принцип переносимости.
import: Используется в <dependencyManagement> для импорта зависимостей из другого POM. Не добавляет зависимость напрямую.
Maven при разрешении зависимостей создает граф зависимостей в памяти (используя org.apache.maven.artifact.Artifact). Для каждого артефакта хранится его scope, что влияет на classpath для различных фаз сборки. Например, test зависимости добавляются только в classpath для фазы test.
Exclusions и конфликт зависимостей
Конфликты зависимостей возникают, когда разные версии одной и той же библиотеки включаются через транзитивные зависимости. Maven решает конфликты, выбирая ближайшую к корню графа версию (стратегия "nearest wins"). Это может привести к проблемам, если выбранная версия несовместима.
Для исключения нежелательных транзитивных зависимостей используется тег <exclusions>:
В памяти Maven модифицирует граф зависимостей, удаляя исключенные артефакты. Это происходит на этапе разрешения зависимостей (dependency:resolve).
Для диагностики конфликтов полезна команда:
#Java #middle #Maven #pom
Тег <properties> позволяет определять пользовательские переменные, которые можно использовать в других частях pom.xml. Это улучшает читаемость и упрощает управление конфигурацией.
Пример:
<properties>
<java.version>11</java.version>
<spring.version>5.3.10</spring.version>
</properties>
Переменные используются через синтаксис ${property.name}.
Например:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
Maven при парсинге pom.xml заменяет все ${...} на соответствующие значения. Это происходит на этапе создания модели в памяти. Если свойство не найдено, Maven пытается использовать системные свойства JVM или переменные окружения. Если и это не удается, сборка завершится ошибкой.
Свойства также могут быть переопределены через командную строку:
mvn clean install -Djava.version=17
В памяти свойства хранятся в объекте Properties внутри модели Model. Они доступны всем плагинам и процессам сборки.
Важный нюанс: свойства не наследуются автоматически в дочерних модулях, если они определены в <properties> родительского POM. Для этого нужно использовать <dependencyManagement> или <pluginManagement>.
<dependencies>: Управление зависимостями
Тег <dependencies> определяет библиотеки, необходимые проекту. Каждая зависимость описывается тегом <dependency> с обязательными полями groupId, artifactId и version.
Scope'ы зависимостей
Атрибут <scope> определяет область применения зависимости:
compile: Зависимость доступна для компиляции, тестирования и выполнения. Включается в итоговый артефакт (например, в jar). Это значение по умолчанию.
provided: Зависимость нужна для компиляции, но предоставляется средой выполнения (например, сервлет API в контейнере). Не включается в итоговый артефакт.
runtime: Зависимость нужна только во время выполнения (например, JDBC-драйвер). Не используется при компиляции.
test: Зависимость нужна только для тестирования (например, JUnit). Не включается в итоговый артефакт.
system: Указывает локальный путь к зависимости через <systemPath>. Используется редко, так как нарушает принцип переносимости.
import: Используется в <dependencyManagement> для импорта зависимостей из другого POM. Не добавляет зависимость напрямую.
Maven при разрешении зависимостей создает граф зависимостей в памяти (используя org.apache.maven.artifact.Artifact). Для каждого артефакта хранится его scope, что влияет на classpath для различных фаз сборки. Например, test зависимости добавляются только в classpath для фазы test.
Exclusions и конфликт зависимостей
Конфликты зависимостей возникают, когда разные версии одной и той же библиотеки включаются через транзитивные зависимости. Maven решает конфликты, выбирая ближайшую к корню графа версию (стратегия "nearest wins"). Это может привести к проблемам, если выбранная версия несовместима.
Для исключения нежелательных транзитивных зависимостей используется тег <exclusions>:
<dependency>
<groupId>org.example</groupId>
<artifactId>lib-a</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>org.unwanted</groupId>
<artifactId>unwanted-lib</artifactId>
</exclusion>
</exclusions>
</dependency>
В памяти Maven модифицирует граф зависимостей, удаляя исключенные артефакты. Это происходит на этапе разрешения зависимостей (dependency:resolve).
Для диагностики конфликтов полезна команда:
mvn dependency:tree
#Java #middle #Maven #pom
<dependencyManagement>: Централизованный контроль зависимостей
Тег <dependencyManagement> позволяет определять версии и настройки зависимостей, которые будут использоваться в проекте или его модулях. Это особенно полезно в многомодульных проектах.
Пример:
Зависимости из <dependencyManagement> не добавляются в проект автоматически. Они активируются только при указании groupId и artifactId в <dependencies> без версии. Это позволяет централизовать управление версиями в родительском POM.
В памяти Maven хранит эти зависимости в объекте DependencyManagement, который используется для разрешения версий при парсинге дочерних POM. Это снижает риск конфликтов версий в многомодульных проектах.
<build> и <plugins>
Тег <build> определяет процесс сборки проекта. Он включает настройки каталогов, плагинов и другие параметры.
Основные дочерние элементы:
<sourceDirectory>: Путь к исходному коду (по умолчанию src/main/java).
<testSourceDirectory>: Путь к тестам (по умолчанию src/test/java).
<resources>: Ресурсы, включаемые в артефакт.
<plugins>: Список плагинов для выполнения задач.
Пример плагина:
Каждый плагин привязан к фазам жизненного цикла Maven (например, compile, test, package). Плагины выполняются в JVM как отдельные классы, загружаемые через собственный класслоадер Maven. В памяти создается объект Plugin, содержащий конфигурацию и привязки к фазам.
Тег <pluginManagement> работает аналогично <dependencyManagement>, позволяя задавать конфигурацию плагинов для наследования в дочерних модулях.
<profiles>: Профили сборки
Профили позволяют настраивать сборку под разные окружения (например, dev, prod). Тег <profiles> содержит список <profile>.
Пример:
Профиль активируется через:
Командную строку: mvn clean install -Pdev.
Условия в <activation> (например, по OS, JDK или наличию файла).
Maven при парсинге объединяет активный профиль с основным pom.xml. Это происходит в памяти, где профиль мержится с моделью Model. Если несколько профилей активны, они применяются в порядке определения.
<repositories> и <pluginRepositories>
Теги <repositories> и <pluginRepositories> указывают, где Maven должен искать зависимости и плагины. По умолчанию используется центральный репозиторий Maven (https://repo.maven.apache.org/maven2).
Пример:
Maven загружает артефакты сначала из локального репозитория (~/.m2/repository), затем из указанных репозиториев. В памяти создается список объектов Repository, которые используются резолвером зависимостей.
#Java #middle #Maven #pom
Тег <dependencyManagement> позволяет определять версии и настройки зависимостей, которые будут использоваться в проекте или его модулях. Это особенно полезно в многомодульных проектах.
Пример:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.3.10</version>
</dependency>
</dependencies>
</dependencyManagement>
Зависимости из <dependencyManagement> не добавляются в проект автоматически. Они активируются только при указании groupId и artifactId в <dependencies> без версии. Это позволяет централизовать управление версиями в родительском POM.
В памяти Maven хранит эти зависимости в объекте DependencyManagement, который используется для разрешения версий при парсинге дочерних POM. Это снижает риск конфликтов версий в многомодульных проектах.
<build> и <plugins>
Тег <build> определяет процесс сборки проекта. Он включает настройки каталогов, плагинов и другие параметры.
Основные дочерние элементы:
<sourceDirectory>: Путь к исходному коду (по умолчанию src/main/java).
<testSourceDirectory>: Путь к тестам (по умолчанию src/test/java).
<resources>: Ресурсы, включаемые в артефакт.
<plugins>: Список плагинов для выполнения задач.
Пример плагина:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>11</source>
<target>11</target>
</configuration>
</plugin>
Каждый плагин привязан к фазам жизненного цикла Maven (например, compile, test, package). Плагины выполняются в JVM как отдельные классы, загружаемые через собственный класслоадер Maven. В памяти создается объект Plugin, содержащий конфигурацию и привязки к фазам.
Тег <pluginManagement> работает аналогично <dependencyManagement>, позволяя задавать конфигурацию плагинов для наследования в дочерних модулях.
<profiles>: Профили сборки
Профили позволяют настраивать сборку под разные окружения (например, dev, prod). Тег <profiles> содержит список <profile>.
Пример:
<profiles>
<profile>
<id>dev</id>
<properties>
<env>development</env>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<env>production</env>
</properties>
</profile>
</profiles>
Профиль активируется через:
Командную строку: mvn clean install -Pdev.
Условия в <activation> (например, по OS, JDK или наличию файла).
Maven при парсинге объединяет активный профиль с основным pom.xml. Это происходит в памяти, где профиль мержится с моделью Model. Если несколько профилей активны, они применяются в порядке определения.
<repositories> и <pluginRepositories>
Теги <repositories> и <pluginRepositories> указывают, где Maven должен искать зависимости и плагины. По умолчанию используется центральный репозиторий Maven (https://repo.maven.apache.org/maven2).
Пример:
<repositories>
<repository>
<id>custom-repo</id>
<url>https://repo.example.com</url>
</repository>
</repositories>
Maven загружает артефакты сначала из локального репозитория (~/.m2/repository), затем из указанных репозиториев. В памяти создается список объектов Repository, которые используются резолвером зависимостей.
#Java #middle #Maven #pom
Parent POM'ы и наследование
Родительский POM позволяет централизовать конфигурацию для нескольких проектов.
Дочерний проект ссылается на родительский через <parent>:
Maven при парсинге загружает родительский POM и объединяет его с дочерним.
Наследуются:
- <dependencyManagement> и <pluginManagement>.
- <properties>.
- <repositories> и <pluginRepositories>.
В памяти создается композитная модель Model, где дочерний POM имеет приоритет над родительским. Это позволяет переопределять настройки. Однако <dependencies> и <plugins> не наследуются напрямую, чтобы избежать нежелательных включений.
Нюансы работы в памяти
Maven при запуске создает в JVM объектную модель проекта:
Парсинг pom.xml с помощью библиотеки plexus-utils и создание объекта org.apache.maven.model.Model.
Разрешение переменных ${...} с учетом <properties>, системных свойств и окружения.
Построение графа зависимостей с использованием Aether (библиотека для работы с репозиториями).
Создание плана выполнения (execution plan), где плагины привязываются к фазам жизненного цикла.
Каждый плагин выполняется в изолированном класслоадере, чтобы избежать конфликтов зависимостей. Локальный репозиторий (~/.m2/repository) кэширует артефакты, минимизируя сетевые запросы. Для SNAPSHOT-версий Maven периодически проверяет обновления в удаленных репозиториях.
#Java #middle #Maven #Pom
Родительский POM позволяет централизовать конфигурацию для нескольких проектов.
Дочерний проект ссылается на родительский через <parent>:
<parent>
<groupId>com.example</groupId>
<artifactId>parent-project</artifactId>
<version>1.0</version>
</parent>
Maven при парсинге загружает родительский POM и объединяет его с дочерним.
Наследуются:
- <dependencyManagement> и <pluginManagement>.
- <properties>.
- <repositories> и <pluginRepositories>.
В памяти создается композитная модель Model, где дочерний POM имеет приоритет над родительским. Это позволяет переопределять настройки. Однако <dependencies> и <plugins> не наследуются напрямую, чтобы избежать нежелательных включений.
Нюансы работы в памяти
Maven при запуске создает в JVM объектную модель проекта:
Парсинг pom.xml с помощью библиотеки plexus-utils и создание объекта org.apache.maven.model.Model.
Разрешение переменных ${...} с учетом <properties>, системных свойств и окружения.
Построение графа зависимостей с использованием Aether (библиотека для работы с репозиториями).
Создание плана выполнения (execution plan), где плагины привязываются к фазам жизненного цикла.
Каждый плагин выполняется в изолированном класслоадере, чтобы избежать конфликтов зависимостей. Локальный репозиторий (~/.m2/repository) кэширует артефакты, минимизируя сетевые запросы. Для SNAPSHOT-версий Maven периодически проверяет обновления в удаленных репозиториях.
#Java #middle #Maven #Pom
Что выведет код?
#Tasks
import java.util.function.Consumer;
public class Task250625 {
public static void main(String[] args) {
Consumer<String> c1 = s -> System.out.print("A" + s);
Consumer<String> c2 = s -> System.out.print("B" + s);
c1.andThen(c2).accept("1");
c2.andThen(c1).accept("2");
}
}
#Tasks
Что такое ThreadLocal? 🤓
Ответ:
ThreadLocal предоставляет каждой нити свою копию переменной, изолируя данные между потоками.
Полезно для хранения контекста, например, пользовательской сессии.
Пример:
ThreadLocal<Integer> threadId = ThreadLocal.withInitial(() -> Thread.currentThread().getId());
System.out.println(threadId.get());
// Уникальный ID для каждого потока
После использования нужно вызывать remove() для предотвращения утечек памяти.
#собеседование
Ответ:
Полезно для хранения контекста, например, пользовательской сессии.
Пример:
ThreadLocal<Integer> threadId = ThreadLocal.withInitial(() -> Thread.currentThread().getId());
System.out.println(threadId.get());
// Уникальный ID для каждого потока
После использования нужно вызывать remove() для предотвращения утечек памяти.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
Автоупаковка и автораспаковка типов в Java
Java разделяет примитивные типы (int, boolean, char и др.) и ссылочные типы (в том числе классы-обертки Integer, Boolean, Character и т.д.). Чтобы упростить работу с обертками, Java (начиная с версии 1.5) ввела механизм автоупаковки (autoboxing) и автораспаковки (unboxing) — автоматическое преобразование между примитивами и их объектными аналогами.
Автоупаковка (Autoboxing)
Это автоматическое преобразование примитива в объект соответствующего класса-обертки.
Пример:
Java компилятор сам преобразует это в:
Автораспаковка (Unboxing)
Обратное преобразование — объект-обертка в примитив.
Пример:
На самом деле компилятор превращает это в:
Как это работает в памяти
До автоупаковки
С автоупаковкой
Примеры использования
Зачем нужна автоупаковка
Унификация с коллекциями
Удобство синтаксиса
Писать проще и чище:
Обратная совместимость
Автоупаковка позволяет использовать новые коллекции с примитивами, не ломая старый код.
Подводные камни
1. NullPointerException
Автораспаковка объекта, равного null, вызывает исключение:
2. Производительность
Автоупаковка создает лишние объекты, особенно в циклах:
Альтернатива:
3. Сравнение ссылок
А вот:
Потому что:
Integer.valueOf(...) кэширует значения от -128 до 127.
== сравнивает ссылки, а не значения.
4. Неявное создание объектов
Может вызвать нагрузку на сборщик мусора, если упакованные значения активно создаются и исчезают, особенно в многопоточной среде.
Разбор кэширования (Integer Cache)
Это реализовано внутри Integer.valueOf():
Практические советы
Используйте примитивы, если нет необходимости в объектах (например, в счетчиках, математике).
Избегайте упаковки в горячих циклах, особенно в производительном коде.
Будьте осторожны с null — автораспаковка null всегда приведет к ошибке.
Для сравнения используйте equals(), а не ==.
#Java #для_новичков #beginner #reference_types #Autoboxing #Unboxing
Java разделяет примитивные типы (int, boolean, char и др.) и ссылочные типы (в том числе классы-обертки Integer, Boolean, Character и т.д.). Чтобы упростить работу с обертками, Java (начиная с версии 1.5) ввела механизм автоупаковки (autoboxing) и автораспаковки (unboxing) — автоматическое преобразование между примитивами и их объектными аналогами.
Автоупаковка (Autoboxing)
Это автоматическое преобразование примитива в объект соответствующего класса-обертки.
Пример:
Integer x = 5; // int -> Integer автоматически
Java компилятор сам преобразует это в:
Integer x = Integer.valueOf(5);
Автораспаковка (Unboxing)
Обратное преобразование — объект-обертка в примитив.
Пример:
int y = x; // Integer -> int автоматически
На самом деле компилятор превращает это в:
int y = x.intValue();
Как это работает в памяти
До автоупаковки
int x = 10;
Integer y = new Integer(x); // вручную
x — хранится в стеке, занимает 4 байта.
y — объект в куче, содержит поле типа int со значением 10 и дополнительную информацию (например, hashCode, class pointer и т.д.).
С автоупаковкой
Integer z = 10;
Компилятор заменит это на Integer.valueOf(10), что использует кэш оберток от -128 до 127.
Примеры использования
List<Integer> numbers = new ArrayList<>();
numbers.add(10); // int -> Integer (autoboxing)
int n = numbers.get(0); // Integer -> int (unboxing)
Это работает, потому что ArrayList хранит только объекты, а int автоматически упаковывается и распаковывается.
Зачем нужна автоупаковка
Унификация с коллекциями
List<Integer> list = new ArrayList<>();
list.add(42); // без ручного создания new Integer(42)
Удобство синтаксиса
Писать проще и чище:
Integer sum = 0;
for (int i = 0; i < 10; i++) {
sum += i; // автораспаковка и автоупаковка
}
Обратная совместимость
Автоупаковка позволяет использовать новые коллекции с примитивами, не ломая старый код.
Подводные камни
1. NullPointerException
Автораспаковка объекта, равного null, вызывает исключение:
Integer x = null;
int y = x; // NullPointerException
2. Производительность
Автоупаковка создает лишние объекты, особенно в циклах:
Integer sum = 0;
for (int i = 0; i < 1000; i++) {
sum += i; // каждый шаг — распаковка, сложение, упаковка
}
Альтернатива:
int sum = 0; // быстрее и без накладных расходов
3. Сравнение ссылок
Integer a = 1000;
Integer b = 1000;
System.out.println(a == b); // false
А вот:
Integer a = 100;
Integer b = 100;
System.out.println(a == b); // true — значения из кэша
Потому что:
Integer.valueOf(...) кэширует значения от -128 до 127.
== сравнивает ссылки, а не значения.
4. Неявное создание объектов
Может вызвать нагрузку на сборщик мусора, если упакованные значения активно создаются и исчезают, особенно в многопоточной среде.
Разбор кэширования (Integer Cache)
Integer x = 127;
Integer y = 127;
System.out.println(x == y); // true
Integer x = 128;
Integer y = 128;
System.out.println(x == y); // false
Причина — кэш для Integer в диапазоне [-128; 127].
Это реализовано внутри Integer.valueOf():
public static Integer valueOf(int i) {
if (i >= -128 && i <= 127)
return IntegerCache.cache[i + 128];
else
return new Integer(i);
}
Практические советы
Используйте примитивы, если нет необходимости в объектах (например, в счетчиках, математике).
Избегайте упаковки в горячих циклах, особенно в производительном коде.
Будьте осторожны с null — автораспаковка null всегда приведет к ошибке.
Для сравнения используйте equals(), а не ==.
#Java #для_новичков #beginner #reference_types #Autoboxing #Unboxing
Что выведет код?
#Tasks
public class Task260625 {
public static void main(String[] args) {
Integer a = 100;
Integer b = 100;
Integer c = 200;
Integer d = 200;
System.out.println((a == b) + " " + (c == d));
}
}
#Tasks
Варианты ответа:
Anonymous Quiz
14%
"true true"
18%
"false false"
54%
"true false"
14%
"Ошибка компиляции"
Что такое enum в Java? 🤓
Ответ:
enum — это специальный тип для представления фиксированного набора констант.
Каждый элемент enum — это объект класса. Поддерживает методы и поля.
Пример:
enum Day {
MONDAY, TUESDAY;
public String getName() { return name().toLowerCase(); }
}
Используется для типобезопасных констант, например, дней недели или статусов.
#собеседование
Ответ:
Каждый элемент enum — это объект класса. Поддерживает методы и поля.
Пример:
enum Day {
MONDAY, TUESDAY;
public String getName() { return name().toLowerCase(); }
}
Используется для типобезопасных констант, например, дней недели или статусов.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
Жизненный цикл Maven: Полное понимание фаз и процессов
Maven — это мощный инструмент управления сборкой проектов, ядро которого составляет концепция жизненного цикла. Жизненный цикл Maven определяет последовательность фаз, через которые проходит проект во время сборки, обеспечивая предсказуемость и структурированность процесса.
Структура жизненного цикла Maven
Maven использует три основных жизненных цикла, каждый из которых представляет собой набор фаз, выполняемых последовательно для достижения определенной цели. Эти циклы — Clean, Default (Build) и Site — охватывают различные аспекты работы с проектом, от очистки до развертывания документации.
Clean Lifecycle
Жизненный цикл Clean отвечает за удаление артефактов, созданных в процессе предыдущих сборок, чтобы обеспечить чистую рабочую среду.
Он состоит из трех фаз:
pre-clean: Подготовка к очистке. На этой фазе выполняются предварительные действия, такие как завершение незавершенных процессов или освобождение ресурсов. Плагины редко привязаны к этой фазе, но она может использоваться для пользовательских задач, например, для проверки состояния проекта перед очисткой.
clean: Основная фаза очистки. Удаляет директорию target, содержащую скомпилированные классы, JAR-файлы, WAR-файлы и другие артефакты. По умолчанию к этой фазе привязан плагин maven-clean-plugin с целью clean.
post-clean: Завершающие действия после очистки. Эта фаза редко используется, но может быть полезна для выполнения дополнительных операций, таких как логирование или уведомления.
В памяти на этапе Clean происходит освобождение ресурсов, связанных с предыдущими сборками. Maven загружает конфигурацию проекта (POM-файл) в оперативную память, создает объектную модель проекта (POM model), которая хранит метаданные о проекте, зависимостях и плагинах. Во время выполнения clean Maven взаимодействует с файловой системой, удаляя указанные директории, что минимизирует использование памяти, так как не создаются новые артефакты.
Default (Build) Lifecycle
Default — наиболее важный жизненный цикл, охватывающий процесс сборки, тестирования и развертывания артефактов.
Он включает множество фаз, из которых наиболее часто используемые:
validate: Проверяет корректность структуры проекта и наличие всех необходимых ресурсов, таких как POM-файл и зависимости. Maven загружает и валидирует модель POM, проверяя синтаксис и доступность репозиториев.
compile: Компилирует исходный код проекта. По умолчанию используется maven-compiler-plugin, который преобразует Java-файлы в байт-код, сохраняя его в директории target/classes.
test: Выполняет модульные тесты с использованием плагинов, таких как maven-surefire-plugin. Тесты запускаются в изолированной среде, а результаты сохраняются в target/surefire-reports.
package: Создает артефакт (JAR, WAR, EAR и т.д.) на основе скомпилированного кода и ресурсов. Используется, например, maven-jar-plugin для создания JAR-файлов.
verify: Проверяет качество артефакта, выполняя интеграционные тесты или проверки, например, с помощью maven-failsafe-plugin.
install: Устанавливает артефакт в локальный репозиторий (~/.m2/repository), делая его доступным для других локальных проектов.
deploy: Разворачивает артефакт в удаленный репозиторий для общего использования. Используется maven-deploy-plugin.
Каждая фаза Default цикла добавляет новые данные в директорию target, что увеличивает объем используемой памяти. Например, во время компиляции Maven загружает в память исходные файлы, зависимости и настройки компилятора. Плагины, такие как maven-compiler-plugin, создают временные структуры данных для хранения промежуточного байт-кода перед его записью на диск. Это может быть критично для крупных проектов, где объем памяти, необходимый для хранения классов и ресурсов, значительно возрастает.
#Java #middle #Maven #LifeCicle
Maven — это мощный инструмент управления сборкой проектов, ядро которого составляет концепция жизненного цикла. Жизненный цикл Maven определяет последовательность фаз, через которые проходит проект во время сборки, обеспечивая предсказуемость и структурированность процесса.
Структура жизненного цикла Maven
Maven использует три основных жизненных цикла, каждый из которых представляет собой набор фаз, выполняемых последовательно для достижения определенной цели. Эти циклы — Clean, Default (Build) и Site — охватывают различные аспекты работы с проектом, от очистки до развертывания документации.
Clean Lifecycle
Жизненный цикл Clean отвечает за удаление артефактов, созданных в процессе предыдущих сборок, чтобы обеспечить чистую рабочую среду.
Он состоит из трех фаз:
pre-clean: Подготовка к очистке. На этой фазе выполняются предварительные действия, такие как завершение незавершенных процессов или освобождение ресурсов. Плагины редко привязаны к этой фазе, но она может использоваться для пользовательских задач, например, для проверки состояния проекта перед очисткой.
clean: Основная фаза очистки. Удаляет директорию target, содержащую скомпилированные классы, JAR-файлы, WAR-файлы и другие артефакты. По умолчанию к этой фазе привязан плагин maven-clean-plugin с целью clean.
post-clean: Завершающие действия после очистки. Эта фаза редко используется, но может быть полезна для выполнения дополнительных операций, таких как логирование или уведомления.
В памяти на этапе Clean происходит освобождение ресурсов, связанных с предыдущими сборками. Maven загружает конфигурацию проекта (POM-файл) в оперативную память, создает объектную модель проекта (POM model), которая хранит метаданные о проекте, зависимостях и плагинах. Во время выполнения clean Maven взаимодействует с файловой системой, удаляя указанные директории, что минимизирует использование памяти, так как не создаются новые артефакты.
Default (Build) Lifecycle
Default — наиболее важный жизненный цикл, охватывающий процесс сборки, тестирования и развертывания артефактов.
Он включает множество фаз, из которых наиболее часто используемые:
validate: Проверяет корректность структуры проекта и наличие всех необходимых ресурсов, таких как POM-файл и зависимости. Maven загружает и валидирует модель POM, проверяя синтаксис и доступность репозиториев.
compile: Компилирует исходный код проекта. По умолчанию используется maven-compiler-plugin, который преобразует Java-файлы в байт-код, сохраняя его в директории target/classes.
test: Выполняет модульные тесты с использованием плагинов, таких как maven-surefire-plugin. Тесты запускаются в изолированной среде, а результаты сохраняются в target/surefire-reports.
package: Создает артефакт (JAR, WAR, EAR и т.д.) на основе скомпилированного кода и ресурсов. Используется, например, maven-jar-plugin для создания JAR-файлов.
verify: Проверяет качество артефакта, выполняя интеграционные тесты или проверки, например, с помощью maven-failsafe-plugin.
install: Устанавливает артефакт в локальный репозиторий (~/.m2/repository), делая его доступным для других локальных проектов.
deploy: Разворачивает артефакт в удаленный репозиторий для общего использования. Используется maven-deploy-plugin.
Каждая фаза Default цикла добавляет новые данные в директорию target, что увеличивает объем используемой памяти. Например, во время компиляции Maven загружает в память исходные файлы, зависимости и настройки компилятора. Плагины, такие как maven-compiler-plugin, создают временные структуры данных для хранения промежуточного байт-кода перед его записью на диск. Это может быть критично для крупных проектов, где объем памяти, необходимый для хранения классов и ресурсов, значительно возрастает.
#Java #middle #Maven #LifeCicle
Site Lifecycle
Site цикл отвечает за генерацию и развертывание документации проекта.
Он включает две фазы:
site: Генерирует документацию, такую как Javadoc или отчеты о покрытии кода, используя плагины вроде maven-site-plugin. Результаты сохраняются в target/site.
site-deploy: Разворачивает сгенерированную документацию на сервер, например, с помощью maven-scm-publish-plugin.
На этапе Site Maven загружает в память шаблоны для генерации документации, а также данные о проекте, такие как зависимости и отчеты. Использование памяти зависит от объема документации и сложности отчетов, например, при генерации Javadoc для большого проекта.
Заказ выполнения фаз и их взаимосвязь
Фазы в каждом жизненном цикле выполняются строго последовательно, и выполнение одной фазы автоматически запускает все предыдущие фазы в рамках того же цикла. Например, вызов mvn install в Default цикле приведет к выполнению всех фаз от validate до install в следующем порядке: validate, compile, test, package, verify, install. Это обеспечивает целостность сборки, так как каждая фаза опирается на результаты предыдущих.
Между циклами нет автоматической связи. Например, выполнение mvn clean не запускает фазы Default цикла. Однако часто используется комбинация циклов, например, mvn clean install, где сначала выполняется очистка, а затем полный цикл сборки. Maven обрабатывает такие команды последовательно, освобождая память после завершения каждого цикла, если это возможно.
В памяти Maven поддерживает объектную модель проекта, которая обновляется на каждой фазе. Например, на фазе compile добавляются данные о скомпилированных классах, а на фазе test — результаты тестов. Если процесс сборки прерывается, Maven сохраняет промежуточные результаты на диске (в target), чтобы минимизировать потери при повторном запуске.
Bindings фаз к плагинам по умолчанию
Каждая фаза жизненного цикла связана с определенными целями (goals) плагинов, которые выполняют конкретные задачи. Maven использует механизм привязки (bindings), чтобы ассоциировать фазы с плагинами.
Например:
Фаза clean привязана к цели clean плагина maven-clean-plugin.
Фаза compile связана с целью compile плагина maven-compiler-plugin.
Фаза test использует цель test плагина maven-surefire-plugin.
Эти привязки определяются в так называемом "super POM" — базовом POM-файле, который наследуется всеми проектами Maven. Super POM задает стандартное поведение, но его можно переопределить в пользовательском POM-файле.
В памяти плагины загружаются как Java-объекты через классовый загрузчик Maven. Каждый плагин создает собственный контекст выполнения, который включает конфигурацию из POM-файла и параметры, переданные через командную строку. Это может приводить к значительному потреблению памяти, особенно если плагин выполняет сложные операции, такие как компиляция или анализ кода.
#Java #middle #Maven #LifeCicle
Site цикл отвечает за генерацию и развертывание документации проекта.
Он включает две фазы:
site: Генерирует документацию, такую как Javadoc или отчеты о покрытии кода, используя плагины вроде maven-site-plugin. Результаты сохраняются в target/site.
site-deploy: Разворачивает сгенерированную документацию на сервер, например, с помощью maven-scm-publish-plugin.
На этапе Site Maven загружает в память шаблоны для генерации документации, а также данные о проекте, такие как зависимости и отчеты. Использование памяти зависит от объема документации и сложности отчетов, например, при генерации Javadoc для большого проекта.
Заказ выполнения фаз и их взаимосвязь
Фазы в каждом жизненном цикле выполняются строго последовательно, и выполнение одной фазы автоматически запускает все предыдущие фазы в рамках того же цикла. Например, вызов mvn install в Default цикле приведет к выполнению всех фаз от validate до install в следующем порядке: validate, compile, test, package, verify, install. Это обеспечивает целостность сборки, так как каждая фаза опирается на результаты предыдущих.
Между циклами нет автоматической связи. Например, выполнение mvn clean не запускает фазы Default цикла. Однако часто используется комбинация циклов, например, mvn clean install, где сначала выполняется очистка, а затем полный цикл сборки. Maven обрабатывает такие команды последовательно, освобождая память после завершения каждого цикла, если это возможно.
В памяти Maven поддерживает объектную модель проекта, которая обновляется на каждой фазе. Например, на фазе compile добавляются данные о скомпилированных классах, а на фазе test — результаты тестов. Если процесс сборки прерывается, Maven сохраняет промежуточные результаты на диске (в target), чтобы минимизировать потери при повторном запуске.
Bindings фаз к плагинам по умолчанию
Каждая фаза жизненного цикла связана с определенными целями (goals) плагинов, которые выполняют конкретные задачи. Maven использует механизм привязки (bindings), чтобы ассоциировать фазы с плагинами.
Например:
Фаза clean привязана к цели clean плагина maven-clean-plugin.
Фаза compile связана с целью compile плагина maven-compiler-plugin.
Фаза test использует цель test плагина maven-surefire-plugin.
Эти привязки определяются в так называемом "super POM" — базовом POM-файле, который наследуется всеми проектами Maven. Super POM задает стандартное поведение, но его можно переопределить в пользовательском POM-файле.
В памяти плагины загружаются как Java-объекты через классовый загрузчик Maven. Каждый плагин создает собственный контекст выполнения, который включает конфигурацию из POM-файла и параметры, переданные через командную строку. Это может приводить к значительному потреблению памяти, особенно если плагин выполняет сложные операции, такие как компиляция или анализ кода.
#Java #middle #Maven #LifeCicle
Переопределение и расширение поведения фаз
Maven позволяет гибко настраивать поведение фаз через пользовательские конфигурации и плагины.
Переопределение возможно несколькими способами:
Изменение настроек плагина в POM-файле. Например, для maven-compiler-plugin можно указать версию Java или дополнительные параметры компиляции:
Эти настройки загружаются в память во время выполнения фазы compile и влияют на поведение плагина.
Добавление пользовательских целей.
Можно привязать дополнительные цели плагинов к существующим фазам. Например, чтобы запустить статический анализ кода на фазе verify:
Пропуск фаз.
Некоторые фазы можно пропустить, задав соответствующие параметры, например, -DskipTests для пропуска тестов на фазе test. Это уменьшает нагрузку на память, так как Maven не загружает плагины и ресурсы, связанные с пропущенной фазой.
Переопределение требует осторожности, так как неправильная конфигурация может нарушить порядок выполнения или зависимости между фазами. Maven хранит конфигурацию плагинов в памяти в виде объектов Mojo (Maven Plugin Objects), которые создаются для каждой цели плагина. Это может привести к увеличению потребления памяти при большом количестве плагинов или сложных конфигураций.
Custom Lifecycles (Создание кастомных жизненных циклов)
Maven позволяет создавать пользовательские жизненные циклы, хотя это редко используется в повседневной практике. Кастомный жизненный цикл определяется в файле components.xml в папке META-INF/plexus проекта.
Пример структуры:
После определения кастомного цикла к его фазам можно привязать плагины в POM-файле.
Например:
Создание кастомного цикла требует загрузки дополнительных компонентов в память, включая пользовательские классы и конфигурации. Maven использует Plexus, контейнер IoC (Inversion of Control), для управления компонентами жизненного цикла. Это увеличивает сложность и потребление памяти, так как Plexus создает дополнительные объекты для обработки кастомных фаз.
Кастомные циклы полезны для специфических проектов, например, для генерации артефактов нестандартного формата или выполнения уникальных процессов сборки. Однако их использование требует глубокого понимания внутренней архитектуры Maven и может усложнить поддержку проекта.
#Java #middle #Maven #LifeCicle
Maven позволяет гибко настраивать поведение фаз через пользовательские конфигурации и плагины.
Переопределение возможно несколькими способами:
Изменение настроек плагина в POM-файле. Например, для maven-compiler-plugin можно указать версию Java или дополнительные параметры компиляции:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.10.1</version>
<configuration>
<source>11</source>
<target>11</target>
</configuration>
</plugin>
Эти настройки загружаются в память во время выполнения фазы compile и влияют на поведение плагина.
Добавление пользовательских целей.
Можно привязать дополнительные цели плагинов к существующим фазам. Например, чтобы запустить статический анализ кода на фазе verify:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>3.0.5</version>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
Пропуск фаз.
Некоторые фазы можно пропустить, задав соответствующие параметры, например, -DskipTests для пропуска тестов на фазе test. Это уменьшает нагрузку на память, так как Maven не загружает плагины и ресурсы, связанные с пропущенной фазой.
Переопределение требует осторожности, так как неправильная конфигурация может нарушить порядок выполнения или зависимости между фазами. Maven хранит конфигурацию плагинов в памяти в виде объектов Mojo (Maven Plugin Objects), которые создаются для каждой цели плагина. Это может привести к увеличению потребления памяти при большом количестве плагинов или сложных конфигураций.
Custom Lifecycles (Создание кастомных жизненных циклов)
Maven позволяет создавать пользовательские жизненные циклы, хотя это редко используется в повседневной практике. Кастомный жизненный цикл определяется в файле components.xml в папке META-INF/plexus проекта.
Пример структуры:
<component-set>
<components>
<component>
<role>org.apache.maven.lifecycle.Lifecycle</role>
<implementation>org.apache.maven.lifecycle.DefaultLifecycle</implementation>
<configuration>
<id>custom-lifecycle</id>
<phases>
<phase>custom-phase</phase>
</phases>
</configuration>
</component>
</components>
</component-set>
После определения кастомного цикла к его фазам можно привязать плагины в POM-файле.
Например:
<plugin>
<groupId>com.example</groupId>
<artifactId>custom-plugin</artifactId>
<executions>
<execution>
<phase>custom-phase</phase>
<goals>
<goal>custom-goal</goal>
</goals>
</execution>
</executions>
</plugin>
Создание кастомного цикла требует загрузки дополнительных компонентов в память, включая пользовательские классы и конфигурации. Maven использует Plexus, контейнер IoC (Inversion of Control), для управления компонентами жизненного цикла. Это увеличивает сложность и потребление памяти, так как Plexus создает дополнительные объекты для обработки кастомных фаз.
Кастомные циклы полезны для специфических проектов, например, для генерации артефактов нестандартного формата или выполнения уникальных процессов сборки. Однако их использование требует глубокого понимания внутренней архитектуры Maven и может усложнить поддержку проекта.
#Java #middle #Maven #LifeCicle
Нюансы и внутренние механизмы
Управление памятью.
Maven работает как Java-приложение, и его потребление памяти зависит от размера проекта, количества зависимостей и используемых плагинов.
Основные объекты в памяти:
POM model: Хранит структуру проекта, зависимости и конфигурации. Создается при загрузке POM-файла и обновляется на каждой фазе.
Plugin instances: Каждый плагин создает экземпляр объекта Mojo, который хранит конфигурацию и состояние выполнения.
Classloaders: Maven использует отдельные загрузчики классов для плагинов, чтобы изолировать их зависимости. Это может привести к фрагментации памяти при большом количестве плагинов.
Для оптимизации памяти можно использовать флаги JVM, такие как -Xmx и -Xms, или минимизировать количество одновременно выполняемых плагинов.
Обработка ошибок. Если фаза завершается с ошибкой (например, тест не проходит), Maven прерывает выполнение цикла. Промежуточные результаты сохраняются в target, но объекты в памяти освобождаются сборщиком мусора. Это важно учитывать при отладке, так как повторный запуск может требовать полной перезагрузки модели проекта.
Многомодульные проекты.
В проектах с несколькими модулями Maven создает отдельную модель для каждого модуля, что увеличивает потребление памяти. Фазы выполняются для каждого модуля последовательно, но Maven оптимизирует процесс, кэшируя зависимости в локальном репозитории.
Параллельное выполнение.
С флагом -T (например, -T 4 для четырех потоков) Maven может выполнять фазы параллельно для разных модулей. Это ускоряет сборку, но увеличивает пиковое потребление памяти, так как одновременно обрабатываются несколько моделей POM и плагинов.
Кэширование.
Maven кэширует зависимости и артефакты в локальном репозитории (~/.m2/repository), что снижает нагрузку на сеть и память при повторных сборках. Однако при использовании флага --offline Maven полностью полагается на локальный кэш, что может вызвать ошибки, если зависимости отсутствуют.
#Java #middle #Maven #LifeCicle
Управление памятью.
Maven работает как Java-приложение, и его потребление памяти зависит от размера проекта, количества зависимостей и используемых плагинов.
Основные объекты в памяти:
POM model: Хранит структуру проекта, зависимости и конфигурации. Создается при загрузке POM-файла и обновляется на каждой фазе.
Plugin instances: Каждый плагин создает экземпляр объекта Mojo, который хранит конфигурацию и состояние выполнения.
Classloaders: Maven использует отдельные загрузчики классов для плагинов, чтобы изолировать их зависимости. Это может привести к фрагментации памяти при большом количестве плагинов.
Для оптимизации памяти можно использовать флаги JVM, такие как -Xmx и -Xms, или минимизировать количество одновременно выполняемых плагинов.
Обработка ошибок. Если фаза завершается с ошибкой (например, тест не проходит), Maven прерывает выполнение цикла. Промежуточные результаты сохраняются в target, но объекты в памяти освобождаются сборщиком мусора. Это важно учитывать при отладке, так как повторный запуск может требовать полной перезагрузки модели проекта.
Многомодульные проекты.
В проектах с несколькими модулями Maven создает отдельную модель для каждого модуля, что увеличивает потребление памяти. Фазы выполняются для каждого модуля последовательно, но Maven оптимизирует процесс, кэшируя зависимости в локальном репозитории.
Параллельное выполнение.
С флагом -T (например, -T 4 для четырех потоков) Maven может выполнять фазы параллельно для разных модулей. Это ускоряет сборку, но увеличивает пиковое потребление памяти, так как одновременно обрабатываются несколько моделей POM и плагинов.
Кэширование.
Maven кэширует зависимости и артефакты в локальном репозитории (~/.m2/repository), что снижает нагрузку на сеть и память при повторных сборках. Однако при использовании флага --offline Maven полностью полагается на локальный кэш, что может вызвать ошибки, если зависимости отсутствуют.
#Java #middle #Maven #LifeCicle