Как собрать простейшую java программу с помощью maven

Install / Deploy

If you like to install or deploy artifacts by using the above setup you have to use the flatten-maven-plugin otherwise you will install/deploy artifacts in your repository which will not be consumable by Maven anymore. Such kind of setup will look like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>18</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-parent</artifactId>
  <name>First CI Friendly</name>
  <version>${revision}</version>
  ...
  <properties>
    <revision>1.0.0-SNAPSHOT</revision>
  </properties>

 <build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>flatten-maven-plugin</artifactId>
      <version>1.1.0</version>
      <configuration>
        <updatePomFile>true</updatePomFile>
        <flattenMode>resolveCiFriendliesOnly</flattenMode>
      </configuration>
      <executions>
        <execution>
          <id>flatten</id>
          <phase>process-resources</phase>
          <goals>
            <goal>flatten</goal>
          </goals>
        </execution>
        <execution>
          <id>flatten.clean</id>
          <phase>clean</phase>
          <goals>
            <goal>clean</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
  </build>
  <modules>
    <module>child1</module>
    ..
  </modules>
</project>

Что такое pom.xml?

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

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

Корневой элемент содержит ссылку на схему XML, которая облегчает редактирование и проверку :

<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">

Внутри тега содержится основная и обязательная информация о проекте.

Из каких фаз состоит жизненный цикл сборки Default (Build)?

Default (Build) — это основной жизненный цикл Maven, который используется для сборки проектов. Он включает в себя следующие фазы:

  • validate — проверяет корректность метаинформации о проекте, подтверждает, является ли проект корректным и вся ли необходимая информация доступа для завершения процесса сборки.
  • initialize — инициализирует состояние сборки, например, различные настройки.
  • generate-sources — включает любой исходный код в фазу компиляции.
  • process-sources — обрабатывает исходный код (подготавливает). Например, фильтрует определённые значения.
  • generate-resources — генерирует ресурсы, которые должны быть включены в пакет.
  • process-resources — копирует и отправляет ресурсы в указанную директори. Это фаза перед упаковкой.
  • compile — комплирует исходный код проекта.
  • process-classes — обработка файлов, полученных в результате компляции. Например, оптимизация байт-кода Java классов.
  • generate-test-sources — генерирует любые тестовые ресурсы, которые должны быть включены в фазу компиляции.
  • process-test-sources — обрабатывает исходный код тестов. Например, фильтрует значения.
  • test-compile — компилирует исходный код тестов в указанную директорию тестов.
  • process-test-classes — обрабатывает файлы, полученные в результате компиляции исходного кода тестов.
  • test — запускает тесты классов, используя приемлемый фреймворк юнит-тестирования (например, Junit).
  • prepare-package — выполняет все необходимые операции для подготовки пакета, непосредственно перед упаковкой.
  • package — преобразует скомпилированный код и пакет в дистрибутивный формат. Такие как JAR, WAR или EAR.
  • pre-integration-test — выполняет необходимые действия перед выполнением интеграционных тестов.
  • integration-test — обрабатывает и распаковывает пакет, если необходимо, в среду, где будут выполняться интеграционные тесты.
  • post-integration-test — выполняет действия, необходимые после выполнения интеграционных тестов. Например, освобождение ресурсов.
  • verify — выполняет любые проверки для подтверждения того, что пакет пригоден и отвечает критериям качества.
  • install — переносит пакет в локальный репозитарий, откуда он будет доступен для использования как зависимость в других проектах.
  • deploy — копирует финальный пакет (архив) в удалённый репозитарий для, того, чтобы сделать его доступным другим разработчикам и проектам.

Здесь также необходимо уточнить два момента:

  • Когда мы выполняем команду Maven, например , то будут выполнены фазы до и фаза .
  • Различные задачи Maven будут привязаны к различным фазам жизненного цикла Maven в зависимости от типа архива (JAR/WAR/EAR).

Создание приложения из архетипа

На сайте http://maven.apache.org/guides/introduction/introduction-to-archetypes.html перечислены основные архетипы приложений, но несложно создать свой или найти более специфичный .

Для примера если нам нужно веб-приложение, находим подходящий архетип maven-archetype-webapp. В командной строке в нужном каталоге вводим команду Maven:

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp

Теперь можем видеть наглядную структуру каталогов с говорящими названиями:

  • java — тут будут классы
  • webapp — страницы веб-приложения
  • resources — ресурсы
  • test — unit-тесты

Настройка MANIFEST.MF

Плагин позволяет изменять общие части файла , но иногда нужна более глубокая настройка MANIFEST.MF. Решение состоит из двух частей.

  1. Определите все свои специальные конфигурации в файле «шаблона» MANIFEST.MF.
  2. Настройте на использование файла MANIFEST.MF и введите в него любые настройки Maven.

В качестве примера рассмотрим JAR-файл, содержащий агент Java. Чтобы выполнить агент Java, необходимо определить и разрешения. В листинге 3 показано содержимое такого файла MANIFEST.MF.

Листинг 3. Определение Premain-Class в специализированном файле MANIFEST.MF
Manifest-Version: 1.0
Premain-Class: com.geekcap.openapm.jvm.agent.Agent
Can-Redefine-Classes: true
Can-Retransform-Classes: true
Can-Set-Native-Method-Prefix: true

В указано, что агенту разрешается переопределять и преобразовывать классы. Далее, обновляем , включив файл MANIFEST.MF, как показано в листинге 4.

Листинг 4. Включение Premain-Class
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifestFile>
                          src/main/resources/META-INF/MANIFEST.MF
                        </manifestFile>
                        <manifest>
                            <addClasspath>true</addClasspath>
                            <classpathPrefix>lib/</classpathPrefix>
                            <mainClass>
                              com.geekcap.openapm.ui.PerformanceAnalyzer
                            </mainClass>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>
Maven 3

Maven 2 стал одним из самых популярных и широко используемых инструментов с открытым исходным кодом для управления жизненным циклом Java-приложений. Версия Maven 3, предложенная в сентябре 2010 года в виде alpha 5, привнесла в Maven некоторые долгожданные изменения. В разделе можно узнать, что нового появилось в Maven 3.

Это интересный пример, потому что в нем определен , который позволяет JAR-файлу работать в качестве агента Java, и в то же время содержится , который позволяет JAR-файлу быть исполняемым. В этом конкретном примере я использовал (созданный мной инструмент для отслеживания кода), чтобы определить трассировку кода, которая будет записана агентом Java, и пользовательский интерфейс, который облегчает анализ записанных трассировок. Короче говоря, пример демонстрирует возможности объединения явного файла манифеста с динамическими изменениями.

Деревья зависимостей

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

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

Поиск зависимостей оказывается на удивление простым делом, если знать следующую команду:

mvn dependency:tree

Аргумент отображает все прямые зависимости, а затем показывает все подзависимости (а также их подзависимости и т.д.). Например, в листинге 5 приведен отрывок из клиентской библиотеки, требуемой одной из моих зависимостей.

Листинг 5. Дерево зависимостей Maven
 ------------------------------------------------------------------------
 Building Client library for communicating with the LDE
    task-segment: 
 ------------------------------------------------------------------------
 
 com.lmt.pos:sis-client:jar:2.1.14
 +- org.codehaus.woodstox:woodstox-core-lgpl:jar:4.0.7:compile
 |  \- org.codehaus.woodstox:stax2-api:jar:3.0.1:compile
 +- org.easymock:easymockclassextension:jar:2.5.2:test
 |  +- cglib:cglib-nodep:jar:2.2:test
 |  \- org.objenesis:objenesis:jar:1.2:test

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

Аргумент сэкономил мне много часов диагностики ошибочной сборки; надеюсь, что и для вас он сделает то же самое.

install:install-file

Full name:

org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file

Description:

Installs a file in the local repository.

Attributes:

Executes as an aggregator plugin.

Optional Parameters

Name Type Since Description
String - ArtifactId of the artifact to be installed. Retrieved from POM file
if one is specified or extracted from pom.xml in jar
if available.User property is: artifactId.
String 2.2 Classifier type of the artifact to be installed. For example,
«sources» or «javadoc». Defaults to none which means this is the
project’s main artifact.User property is: classifier.
Boolean 2.1 Generate a minimal POM for the artifact if none is supplied via the
parameter pomFile. Defaults to true if
there is no existing POM in the local repository yet.User property is: generatePom.
String - GroupId of the artifact to be installed. Retrieved from POM file if
one is specified or extracted from pom.xml in jar if
available.User property is: groupId.
File 2.3 The bundled API docs for the artifact.User property is: javadoc.
File 2.2 The path for a specific local repository directory. If not
specified the local repository path configured in the Maven
settings will be used.User property is: localRepositoryPath.
String - Packaging type of the artifact to be installed. Retrieved from POM
file if one is specified or extracted from pom.xml in
jar if available.User property is: packaging.
File 2.1 Location of an existing POM file to be installed alongside the main
artifact, given by the file parameter.User property is: pomFile.
File 2.3 The bundled sources for the artifact.User property is: sources.
String - Version of the artifact to be installed. Retrieved from POM file if
one is specified or extracted from pom.xml in jar if
available.User property is: version.

<artifactId>

ArtifactId of the artifact to be installed. Retrieved from POM file
if one is specified or extracted from pom.xml in jar
if available.

  • Type: java.lang.String
  • Required: No
  • User Property: artifactId

<classifier>

Classifier type of the artifact to be installed. For example,
«sources» or «javadoc». Defaults to none which means this is the
project’s main artifact.

  • Type: java.lang.String
  • Since: 2.2
  • Required: No
  • User Property: classifier

The file to be installed in the local repository.

  • Type: java.io.File
  • Required: Yes
  • User Property: file

<generatePom>

Generate a minimal POM for the artifact if none is supplied via the
parameter pomFile. Defaults to true if
there is no existing POM in the local repository yet.

  • Type: java.lang.Boolean
  • Since: 2.1
  • Required: No
  • User Property: generatePom

<groupId>

GroupId of the artifact to be installed. Retrieved from POM file if
one is specified or extracted from pom.xml in jar if
available.

  • Type: java.lang.String
  • Required: No
  • User Property: groupId

The bundled API docs for the artifact.

  • Type: java.io.File
  • Since: 2.3
  • Required: No
  • User Property: javadoc

<localRepositoryPath>

The path for a specific local repository directory. If not
specified the local repository path configured in the Maven
settings will be used.

  • Type: java.io.File
  • Since: 2.2
  • Required: No
  • User Property: localRepositoryPath

<packaging>

Packaging type of the artifact to be installed. Retrieved from POM
file if one is specified or extracted from pom.xml in
jar if available.

  • Type: java.lang.String
  • Required: No
  • User Property: packaging

<pomFile>

Location of an existing POM file to be installed alongside the main
artifact, given by the file parameter.

  • Type: java.io.File
  • Since: 2.1
  • Required: No
  • User Property: pomFile

The bundled sources for the artifact.

  • Type: java.io.File
  • Since: 2.3
  • Required: No
  • User Property: sources

<version>

Version of the artifact to be installed. Retrieved from POM file if
one is specified or extracted from pom.xml in jar if
available.

  • Type: java.lang.String
  • Required: No
  • User Property: version

История разработки

Maven был создан канадцем Джейсоном ван Зилом (Jason van Zyl) и организованной им фирмой Sonatype. Он начался как подпроект Apache Turbine в 2002 г. В 2003 году Maven был квалифицирован как Apache-проект верхнего уровня, тогда же появилась его первая версия — Maven 1.x. Она была опубликована 13 июля 2004 как версия 1.0. Это происходило, однако, так быстро, что некоторые частности оказались непродуманными. Например, слишком много конфигурации, проблемы с производительностью.

Поэтому концепция была доработана и с 2005 года началась параллельная разработка Maven 2.x, которая была сдана в версии 2.0 19 октября 2005 года.

Maven 1.x не разрабатывается дальше и ограничивается поддержкой пользователей и устранением ошибок.

Разработка Maven 3.0 началась в 2008 г.. После восьми альфа-релизов, первая бета-версия Maven 3.0 была опубликована в октябре 2010 г

Особенное внимание было уделено её обратной совместимости с Maven 2. Для большинства проектов переход от версии Maven 2 к версии Maven 3 не требует никаких изменений.

Разработка Maven происходит в следующих подпроектах:

  • Maven 1.x и Maven 2.x — старые версии Maven-а.
  • Maven 3.x развивает текущую линию продуктов Maven.
  • Plugins разрабатывает большинство Maven-плагинов.
  • Shared Components изготовляет компоненты программного обеспечения, которые могут использоваться всеми другими подпроектами.
  • Ant Tasks позволяет использовать возможности Ant из Maven.
  • Doxia — это фреймворк для генерации контента из форматов Almost Plain Text (APT), Confluence, DocBook, FML (FAQ Markup Language), LaTeX, Rich Text Format (RTF), TWiki, XDoc и XHTML.
  • SCM (Source Code Management) разрабатывает программное обеспечение для подключения Apache к различным системам версионирования как CVS или Subversion.
  • Surefire разрабатывает тест-фреймворк для Maven-а.
  • Wagon готовит абстракцию коммуникационных протоколов как «доступ к файлам», HTTP или FTP.

Apache Maven Assembly Plugin

Introduction

The Assembly Plugin for Maven enables developers to combine project output into a single distributable archive that also contains dependencies, modules, site documentation, and other files.

Your project can easily build distribution «assemblies» using one of the prefabricated assembly descriptors. These descriptors handle many common operations, such as packaging a project’s artifact along with generated documentation into a . Alternatively, your project can provide its own descriptor and assume a much higher level of control over how dependencies, modules, file-sets, and individual files are packaged in the assembly.

Currently it can create distributions in the following formats:

  • zip
  • tar
  • tar.gz (or tgz)
  • tar.bz2 (or tbz2)
  • tar.snappy
  • tar.xz (or txz)
  • jar
  • dir
  • war
  • and any other format that the ArchiveManager has been configured for

If your project wants to package your artifact in an uber-jar, the assembly plugin provides only basic support. For more control, use the Maven Shade Plugin.

To use the Assembly Plugin in Maven, you simply need to:

  • choose or write the assembly descriptor to use,
  • configure the Assembly Plugin in your project’s pom.xml, and
  • run «mvn assembly:single» on your project.

To write your own custom assembly, you will need to refer to the Assembly Descriptor Format reference.

What is an Assembly?

An «assembly» is a group of files, directories, and dependencies that are assembled into an archive format and distributed. For example, assume that a Maven project defines a single JAR artifact that contains both a console application and a Swing application. Such a project could define two «assemblies» that bundle the application with a different set of supporting scripts and dependency sets. One assembly would be the assembly for the console application, and the other assembly could be a Swing application bundled with a slightly different set of dependencies.

The Assembly Plugin provides a descriptor format which allows you to define an arbitrary assembly of files and directories from a project. For example, if your Maven project contains the directory «src/main/bin», you can instruct the Assembly Plugin to copy the contents of this directory to the «bin» directory of an assembly and to change the permissions of the files in the «bin» directory to UNIX mode 755. The parameters for configuring this behavior are supplied to the Assembly Plugin by way of the assembly descriptor.

Goals

The main goal in the assembly plugin is the single goal. It is used to create all assemblies.

For more information about the goals that are available in the Assembly Plugin, see the plugin documentation page.

Assembly and Component Descriptor Schemas (XSD)

  • http://maven.apache.org/xsd/assembly-2.0.0.xsd, http://maven.apache.org/xsd/assembly-component-2.0.0.xsd (for version 3.0 and higher)
  • http://maven.apache.org/xsd/assembly-1.1.3.xsd, http://maven.apache.org/xsd/component-1.1.3.xsd (for version 2.5.4 and higher)
  • http://maven.apache.org/xsd/assembly-1.1.2.xsd, http://maven.apache.org/xsd/component-1.1.2.xsd (for version 2.2 and higher)
  • http://maven.apache.org/xsd/assembly-1.1.1.xsd, http://maven.apache.org/xsd/component-1.1.1.xsd (for version 2.2-beta-4 — 2.2-beta-5)
  • http://maven.apache.org/xsd/assembly-1.1.0.xsd, http://maven.apache.org/xsd/component-1.1.0.xsd (for version 2.2-beta-1 — 2.2-beta-3)
  • http://maven.apache.org/xsd/assembly-1.0.0.xsd, http://maven.apache.org/xsd/component-1.0.0.xsd (for version 2.1 and lower)

Usage

General instructions on how to use the Assembly Plugin can be found on the usage page. Some more specific use cases are described in the examples given below.

If you feel like the plugin is missing a feature or has a defect, you can fill a feature request or bug report in our issue tracker. When creating a new issue, please provide a comprehensive description of your concern. Especially for fixing bugs it is crucial that the developers can reproduce your problem. For this reason, entire debug logs, POMs or most preferably little demo projects attached to the issue are very much appreciated. Of course, patches are welcome, too. Contributors can check out the project from our source repository and will find supplementary information in the guide to helping with Maven.

Examples

To provide you with better understanding on some usages of the Assembly Plugin, you can take a look into the examples which can be found here.

Какие теги pom.xml вы знаете?

Вот некоторые из них:

  • project — описывает проект, это элемент верхнего уровня во всех файлах

  • groupId — по-сути, это имя пакета. Полностью отражается в структуре каталогов
  • artifactId — название проекта. В структуре каталогов не отображается
  • version — версия проекта
  • packaging — определяет, какой тип файла будет собран. Варианты:

  • dependencies — указываются зависимости
  • build — информация о сборке проекта
  • name — это уже необязательое описание проекта. В данном случае его название
  • description — элемент представляет собой общее описание проекта. Это часто используется в генерации документации Maven
  • url — интернет-страница проекта
  • repositories — репозитарии для артефактов
  • pluginRepositories — репозитарии для плагинов Maven

Эта страница содержит переработанные и откорректированные материалы с https://jsehelper.blogspot.com/2016/05/maven-1.html

Плагины

Плагины-это такие же артефакт, как и зависимости, поэтому описываются практически так же.

Вместо раздела dependencies-plugins, dependency-plugin, repositories-pluginRepositories, repository-pluginRepository.

Плагинами maven делает все, даже сборку проекта.

Настройка плагина ля создания проекта для Eclipse с использованием WTP ver. 2.0.

В разделе plugins файла pom.xml прописываем плагин:

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-eclipse-plugin</artifactId>

<configuration>

<wtpversion>2.0</wtpversion>

</configuration>

</plugin>

Теперь идем в командную строку и выполняем:

mvn eclipse:eclipse

Ждем пока Maven найдет все библиотеки в репозитории или скачает их и теперь Maven-проект можно открыть как проект Eclipse.

Однако плагины довольно легко найти, например по запросу «maven tomcat  plugin«.

Заключение:

Maven, в отличие от Ant, описывает конечную структуру проекта, а не пути к ее достижению.

Файл Maven pom.xml

POM означает объектную модель проекта. Файл pom.xml содержит информацию о проекте и информацию о конфигурации для сборки проекта. Он содержит зависимости, каталог сборки, каталог с исходным кодом, каталог с исходным кодом теста, плагин и т. д. Maven просматривает файл pom.xml, а затем выполняет цель. Для создания простого файла pom.xml вам потребуются следующие элементы:

  • project: Корневой элемент файла pom.xml.
  • groupId: вложенный элемент проекта. Он описывает идентификатор проекта.
  • modelVersion: вложенный элемент проекта. Он сообщает вам версию модели.
  • artifactId: вложенный элемент проекта. В нем указывается идентификатор проекта. Артефакт либо создается, либо используется проектом. Примеры артефактов: JAR, исходные и двоичные дистрибутивы, а также WAR.
  • Version: Подэлемент проекта. Он сообщает вам версию артефакта в данной группе.

Ниже показан образец файла pom.xml:

<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"gt;
<modelVersion>4.0.0</modelVersion>
<groupId>com.edureka.application1</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
</project>

В файле pom.xml есть некоторые дополнительные элементы:

  • Packaging: определяет тип упаковки, такой как war, jar и т. д.
  • Scope: определяет область для проекта maven.
  • Url: указывает URL-адрес проекта.
  • Name: определяет имя проекта maven.
  • Dependency: определяет зависимость. Он используется внутри зависимостей.

Пример кода файла pom.xml, показывающий дополнительные элементы:

<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"gt;  
<modelVersion>4.0.0</modelVersion>
<groupId>com.edureka.application1</groupId>
<artifactId>my-application1</artifactId>
<version>1.0</version>
<packaging>jar</packaging>
<name>Maven Quick Start Archetype</name>
<ur>http://maven.apache.org</url>
<dependencies>
<dependency> 
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
<scope>test</scope>
</dependency>  
</dependencies>
</project>

Что такое Maven?

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

Принцип работы:

Здесь есть определенные термины, которые могут быть для вас новыми.

  • Файлы POM: для настройки Maven вам необходимо использовать объектную модель проекта (POM), которая хранится в файле pom.xml. POM включает параметр конфигурации, связанный с Maven. У него также есть цели и плагины. В процессе выполнения Maven считывает цель, ищет POM в каталоге и получает необходимую информацию.
  • Жизненные циклы, фазы и цели сборки.

    • Жизненный цикл сборки — это четко определенная последовательность фаз. Он определяет порядок, в котором цели должны быть выполнены.
    • Каждая фаза построения состоит из последовательности целей. Если выполняется один жизненный цикл, выполняются все фазы сборки в этом жизненном цикле.
    • Если выполняется этап сборки, выполняются все этапы сборки до него в заранее определенной последовательности этапов сборки.
  • Плагины сборки: Maven — это в основном среда выполнения плагинов, и каждая задача выполняется с помощью плагинов. Если для вашего проекта необходимо выполнить определенный набор действий, которые не охватываются стандартными этапами и целями сборки Maven, вы можете добавить плагин в файл POM. У Maven есть несколько стандартных плагинов, которые можно использовать в java-проекте. Плагин фактически ставит перед собой набор целей. Плагины упоминаются в pom.xml с помощью элементов плагина.
  • Профили сборки: профили сборки используются, если вам нужно построить проект несколькими способами. Вы также можете настроить сборку для нескольких сред, таких как среды разработки и разработки. Существует три типа профилей сборки: на профиль, на пользователя, глобальные.
  • Репозиторий: это просто каталог на вашем компьютере. Здесь хранятся jar-файлы проекта, плагины или любые другие материалы, относящиеся к проекту. Есть три разных типа репозиториев:

    • локальные;
    • центральные;
    • удаленные.
Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector