«java-проект от а до я»: все, что вы хотели знать о maven

Сборка Java кода

Теперь все готово для сборки проекта Maven’ом. Вы можете выполнить несколько этапов жизненного цикла сборки,
включая компиляцию кода, создание библиотеки пакета(такого, как JAR-файл) и установку библиотеки в
локальный репозиторий Maven зависимостей.

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

Этим вы запустите Maven, передав ему указание на выполнение задачи compile. Когда он закончит,
вы должны найни скомпилированные .class файлы в target/classes директории.

Вряд ли вы захотите распостранять или работать напрямую с .class файлами, поэтому
вам полее подойдет выполнение задачи package:

Задача package включает компиляцию вашего Java кода, запуск тестов, а в конце упаковывает
в JAR-файл в target директории. Название JAR-файла будет основано на
и . К примеру, с минимальным pom.xml(см. выше), JAR-файл будет иметь
название gs-maven-initial-0.1.0.jar.

Если вы изменили значение с «jar» на «war», то результатом будет
WAR-файл в target директории вместо JAR-файла.

Maven также хранит репозиторий зависимостей на вашей локальной машине(обычно в .m2/repository
директории в вашей домашней папке) для быстрого доступа к зависимостям проекта. Если вы хотите
добавить JAR-файл вашего проекта в локальный репозиторий, тогда вам необходимо выполнить задачу :

Задача install включает компиляцию, тестирование, упаковку кода проекта, а затем
копирование в локальный репозиторий, тем самым другие проекты смогут ссылаться на него как на зависимость.

Говоря о зависимостях, пришло время объявлять зависимости в Maven сборке.

Reporters and Contributors of this release

We really value the contributions of these non committers, so this section is focused on those individuals. Descriptions of the issues fixed can be found at the .

Issue Reporters of this release:

  • MNG-5705 Ondra Žižka
  • MNG-5965 Matthias Schmalz
  • MNG-6059 Andreas Sewe
  • MNG-6159 Christian Aistleitner
  • MNG-6213 Jin Kwon
  • MNG-6256 Christoph Etzel
  • MNG-6261 Dawid Weiss
  • MNG-6262 Gene Smith
  • MNG-6346 Patrik Jetzer
  • MNG-6374 Rohan Padhye
  • MNG-6495 Elliotte Rusty Harold
  • MNG-6506 Andreas Veithen
  • MNG-6526 Olaf Otto
  • MNG-6529 Michael Istria
  • MNG-6530 Michael Istria
  • MNG-6533 Michael Istria
  • MNG-6543 Romain Manni-Bucau
  • MNG-6558 Guy Brand
  • MNG-6577 Rohan Padhye
  • MNG-6591 Olaf Otto
  • MNG-6605 Gunnar Wagenknecht
  • MNG-6618 Viacheslav Yakunin

Code Contributors of this release:

  • MNG-6374 Gabriel Belingueres (indirectly via plexus-utils PR)
  • MNG-6529 Michael Istria
  • MNG-6530 Michael Istria
  • MNG-6558 Guy Brand
  • MNG-6261 Fabiano C. de Oliveira
  • MNG-6533 Michael Istria

Many thanks to all reporters and contributors for their time and support.

Настройка 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 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>

Apache Maven Deploy Plugin

The deploy plugin is primarily used during the deploy phase, to add your artifact(s) to a remote repository for sharing with other developers and projects. This is usually done in an integration or release environment. It can also be used to deploy a particular artifact (e.g. a third party jar like Sun’s non redistributable reference implementations).

As a repository contains more than the artifacts (POMs, the metadata, MD5 and SHA1 hash files…), deploying means not only copying the artifacts, but making sure all this information is correctly updated. It’s the reponsibility of the deploy plugin.

To work, the deployment will require:

  • information about the repository: its location, the transport method used to access it (FTP, SCP, SFTP…) and the optional user specific required account information
  • information about the artifact(s): the group, artifact, version, packaging, classifier…
  • a deployer: a method to actually perform the deployment. This can be implemented as a wagon transport (making it cross-platform), or use a system specific method.

The information will be taken from the implied (or specified) pom and from the command line. The settings.xml file may also be parsed to retrieve user credentials.

Goals Overview

The deploy plugin has 2 goals:

  • deploy:deploy is used to automatically install the artifact, its pom and the attached artifacts produced by a particular project. Most if not all of the information related to the deployment is stored in the project’s pom.
  • deploy:deploy-file is used to install a single artifact along with its pom. In that case the artifact information can be taken from an optionally specified pomFile, but can be completed/overriden using the command line.

Major Version Upgrade to version 3.0.0

Please note that the following parameter has been completely removed from the plugin configuration:

uniqueVersion

As of Maven 3, snapshot artifacts will always be deployed using a timestamped version.

Usage

General instructions on how to use the Deploy 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 deploy plugin, you can take a look into the following examples:

Project Deployment:

  • Deployment with FTP
  • Deployment with external SSH

File Deployment:

  • Disable the generation of pom
  • Deploy an artifact with a customed pom
  • Deploy an artifact with classifier
  • Disable timestamps suffix in an artifact
  • Deploy an artifact in legacy layout

Spring Boot Specification

Spring Boot applications specify the JDK version inside of the properties tags in the pom.xml file.

First, we need to add spring-boot-starter-parent as a parent to our project:

This parent POM allows us to configure default plugins and multiple properties including the Java version: By default, the Java version is 1.8.

However, we can override the default version of the parent by specifying the java.version property:

By setting the java.version property we declare that the source and the target Java versions are both equal to 1.9.

Above all, we should keep in mind that this property is a Spring Boot Specification. Additionally, starting from the Spring Boot 2.0, Java 8 is the minimum version.

This means we can’t use or configure Spring Boot for the older JDK versions.

Introduction

Building a software project typically consists of such tasks as downloading dependencies, putting additional jars on a classpath, compiling source code into binary code, running tests, packaging compiled code into deployable artifacts such as JAR, WAR, and ZIP files, and deploying these artifacts to an application server or repository.

Apache Maven automates these tasks, minimizing the risk of humans making errors while building the software manually and separating the work of compiling and packaging our code from that of code construction.

In this tutorial, we’re going to explore this powerful tool for describing, building, and managing Java software projects using a central piece of information — the Project Object Model (POM) — that is written in XML.

Overview

In this quick tutorial, we’ll show how to set the Java version in Maven.

Before moving ahead, we can check the default JDK version of Maven. Running the mvn -v command will show the Java version in which Maven runs.

2. Use the Compiler Plugin

We can specify the desired Java version in the compiler plugin.

2.1. Compiler Plugin

The first option is setting the version in compiler plugin properties:

The Maven compiler accepts this command with –target and –source versions. If we want to use the Java 8 language features the –source should be set to 1.8.

Also, for the compiled classes to be compatible with JVM 1.8, the –target value should be 1.8.

The default value for both of them is 1.6 version.

Alternatively, we can configure the compiler plugin directly:

The maven-compiler-plugin also has additional configuration properties that allow us to have more control over the compilation process beyond -source and -target versions.

2.2  Java 9 and Beyond

Furthermore, starting from JDK 9 version, we can use a new -release command-line option. This new argument will automatically configure the compiler to produce class files that will link against the implementation of the given platform version.

By default, the -source and -target options don’t guarantee a cross-compilation.

This means that we cannot run our application on older versions of the platform. Additionally, to compile and run the programs for older Java versions, we also need to specify -bootclasspath option.

To cross-compile correctly, the new -release option replaces three flags: -source, -target and -bootclasspath.

After transforming our examples, for the plugin properties we can declare:

And for the maven-compiler-plugin starting from the 3.6 version we can write:

As we notice, we can add the Java version in a new <release> attribute. In this example, we compile our application for Java 7.

Even more, we don’t need a JDK 7 installed in our machine. Java 9 already contains all the information for linking the new language features with JDK 7.

3. Spring Boot Specification

Spring Boot applications specify the JDK version inside of the properties tags in the pom.xml file.

First, we need to add spring-boot-starter-parent as a parent to our project:

This parent POM allows us to configure default plugins and multiple properties including the Java version: By default, the Java version is 1.8.

However, we can override the default version of the parent by specifying the java.version property:

By setting the java.version property we declare that the source and the target Java versions are both equal to 1.9.

Above all, we should keep in mind that this property is a Spring Boot Specification. Additionally, starting from the Spring Boot 2.0, Java 8 is the minimum version.

This means we can’t use or configure Spring Boot for the older JDK versions.

This quick tutorial demonstrates the possible ways of setting Java version in our Maven project.

In summary:

  • Using <java.version> is possible only with the Spring Boot application
  • For simple cases maven.compiler.source and maven.compiler.target properties should be the best-fit
  • Finally, to have more control over the compilation process use the maven-compiler-plugin configuration settings

Apache Maven Filtering

This component has been built from the filtering process/code in Maven Resources Plugin.

The goal is to provide a shared component for all plugins that needs to filter resources.

MavenResourcesExecution

POM Interpolation

POM values will be interpolated only with expressions starting with pom or project (it’s configurable). In previous versions something like ${foo.version} or ${version} was interpolated with the current POM version, but it won’t be interpolated with a POM value any more.

Escaping Interpolation

It’s possible now to define a String which will escape interpolation. \${java.home} will be interpolated to ${java.home}.

overwrite parameter

The parameter overwrite forces file copy even if the destination file is newer.

MavenResourcesFiltering

This component will apply filtering on a List of org.apache.maven.model.Resources.

If you want to use the default List of FileUtils.FilterWrapper (see below) you should use the method without the filterWrappers parameter.

The component will not filter a predefined set of file extensions (jpg, jpeg, gif, bmp, png).

Note: You can easily add extra file extensions.

MavenFileFilter

This component has a method which returns the default FileUtils.FilterWrappers. These are:

  • Interpolation with token ${ } and values from properties files, <project>/<build>/<filters, project.properties and mavenSession.executionProperties
  • Interpolation with token @ @ and values from properties files, <project>/<build>/<filters, project.properties and mavenSession.executionProperties
  • Interpolation with token ${ } and values from mavenProject interpolation
  • Interpolation with token @ @ and values from mavenProject interpolation

The values used for interpolation are stored in a Properties object and are loaded in the following order:

  • A List of properties files, provided as a parameter to the method
  • Filters defined in the <build>/<filters> section of the POM
  • Properties defined in the <properties> section of the POM
  • The executionProperties from the current MavenSession

Note: As it’s a Properties object, the last defined key/value pair wins.

Note: When building the Properties object and reading the properties files that defines the different filters, interpolation with the token ${ } is supported for these filters with limited properties values coming from project.properties and mavenSession.executionProperties. The last wins here too.

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>

Multi Module Setup

So now let us take a look into a situation where we have a multi module build. We have a parent pom and one or more children. The parent pom 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>
  <modules>
    <module>child1</module>
    ..
  </modules>
</project>

The child will look like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache.maven.ci</groupId>
    <artifactId>ci-parent</artifactId>
    <version>${revision}</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-child</artifactId>
   ...
</project>

Apache Maven Site Plugin

The Site Plugin is used to generate a site for the project. The generated site also includes the project’s reports that were configured in the POM.

Please read the migration guide if you want to upgrade from a previous version.

Goals Overview

The Site Plugin has seven goals:

  • site:site is used generate a site for a single project. Note that links between module sites in a multi module build will not work, since local build directory structure doesn’t match deployed site.
  • site:deploy is used to deploy the generated site using Wagon supported protocol to the site URL specified in the <distributionManagement> section of the POM.
  • site:run starts the site up, rendering documents as requested for faster editing. It uses Jetty as the web server.
  • site:stage generates a site in a local staging or mock directory based on the site URL specified in the <distributionManagement> section of the POM. It can be used to test that links between module sites in a multi module build work. This goal requires the site to already have been generated using the site goal, such as by calling mvn site.
  • site:stage-deploy deploys the generated site to a staging or mock directory to the site URL specified in the <distributionManagement> section of the POM.
  • site:attach-descriptor adds the site descriptor (site.xml) to the list of files to be installed/deployed. For more references of the site descriptor, here’s a link.
  • site:jar bundles the site output into a JAR so that it can be deployed to a repository.
  • site:effective-site calculates the effective site descriptor, after inheritance and interpolation.

Usage

General instructions on how to use the Site 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 file 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

The following examples show how to use the Site Plugin in more advanced use cases:

  • Creating Content
  • Configuring the Site Descriptor
  • Configuring Site Run
  • Excluding Document Formats

Примеры плагинов

3.1. Плагин maven-archetype-plugin

Плагин maven-archetype-plugin предназначен для того чтобы по существующему шаблону создавать новые проекты. Создать проект с помощью maven-archetype-plugin достаточно просто — достаточно набрать:

Дальше выбрать шаблон из списка, ответить на дополнительные вопросы — и плагин сгенерирует проект. 

3.2. Плагин maven-compiler-plugin

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

В следующем примере в конфигурации используется версия java 1.9 (source — версия языка, на котором написана программа. А target — версия Java машины которая будет этот код запускать). И указано, что кодировка исходного кода программы UTF-8.

Пример 3. Использование плагина maven-compiler-plugin

3.3. Плагин maven-javadoc-plugin

Плагин maven-javadoc-plugin предназначен для того, чтобы генерировать документацию по исходному коду проекта стандартной утилитой javadoc. 

Запускается с помощью команды:

Документация генерируется в target/site/apidocs каталог текущего проекта.

3.4. Плагин maven-checkstyle-plugin

Плагин проверяет стиль и качество исходного кода и генерирует файл checkstyle-result.xml. Из наиболее часто используемых и простых проверок:

  • наличие комментариев;
  • размер класса не более N строк;
  • в конструкции в try-catch, блок catch не пуст. 

Запуск с помощью команды:

Т.к. почти каждые проекты пишутся немного по-разному, рекомендуется создать свой набор правил. Или подавить проверку некоторых правил. Для этого используется файл suppressions.xml. 

Пример 5. Файл suppressions.xml

3.5. Плагин maven-pmd-plugin

maven-pmd-plugin — плагин для автоматического анализа кода на предмет наличия «нехорошего кода». Также в этом плагине есть цель которая находит дубликаты кода Copy/Paste Detector (CPD).

Существует два режима работы плагина:

  • Генерирование отчётов PMD и CPD:

    полезно для оценки качества существующих проектов которые раньше не использовали эти инструменты. Позволяет оценить масштабы «бедствия».

  • Проверка проект на наличие нарушений. В случае, если находится нарушение, сборка ломается:

3.6. Плагин findbugs-maven-plugin

findbugs-maven-plugin плагин для автоматического нахождения багов в проекте. Принцип действия плагина основан на поиске шаблонов ошибок. Код проекта проверяются на часто встречаемые ошибки, неправильное использование API и конструкций языка.

Запускаем с помощью

Feature Summary

The following are the key features of Maven in a nutshell:

  • Simple project setup that follows best practices — get a new project or module started in seconds
  • Consistent usage across all projects — means no ramp up time for new developers coming onto a project
  • Superior dependency management including automatic updating, dependency closures (also known as transitive dependencies)
  • Able to easily work with multiple projects at the same time
  • A large and growing repository of libraries and metadata to use out of the box, and arrangements in place with the largest Open Source projects for real-time availability of their latest releases
  • Extensible, with the ability to easily write plugins in Java or scripting languages
  • Instant access to new features with little or no extra configuration
  • Ant tasks for dependency management and deployment outside of Maven
  • Model based builds: Maven is able to build any number of projects into predefined output types such as a JAR, WAR, or distribution based on metadata about the project, without the need to do any scripting in most cases.
  • Coherent site of project information: Using the same metadata as for the build process, Maven is able to generate a web site or PDF including any documentation you care to add, and adds to that standard reports about the state of development of the project. Examples of this information can be seen at the bottom of the left-hand navigation of this site under the «Project Information» and «Project Reports» submenus.
  • Release management and distribution publication: Without much additional configuration, Maven will integrate with your source control system (such as Subversion or Git) and manage the release of a project based on a certain tag. It can also publish this to a distribution location for use by other projects. Maven is able to publish individual outputs such as a JAR, an archive including other dependencies and documentation, or as a source distribution.
  • Dependency management: Maven encourages the use of a central repository of JARs and other dependencies. Maven comes with a mechanism that your project’s clients can use to download any JARs required for building your project from a central JAR repository much like Perl’s CPAN. This allows users of Maven to reuse JARs across projects and encourages communication between projects to ensure that backward compatibility issues are dealt with.

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

На сайте 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-тесты

Single Project Setup

This can 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>
  ...
</project>

This is of course a simple situation where we use only for brevity to show the general course.

Based on the above pom you can build your project using:

mvn clean package

But wait there is a problem? Which version will the artifacts have? So you need to define the version for your artifacts. The first possibility is to use the command line like this:

mvn -Drevision=1.0.0-SNAPSHOT clean package

This will become cumbersome over the time. So the other solution for this is to simply use a property inside the pom file which looks 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>
</project>

So now you can simply call Maven as usual like .

You can of course change the version via the command line like this:

mvn -Drevision=2.0.0-SNAPSHOT clean package

Of course you can use the file for this.

A note about the used properties. You can only use those named , and/or and not other named properties 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-${buildNumber}-SNAPSHOT</revision>
  </properties>
</project>

The above example will not work as expected. If you like to have more flexibility you can use a combination of the different properties 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}${sha1}${changelist}</version>
  ...
  <properties>
    <revision>1.3.1</revision>
    <changelist>-SNAPSHOT</changelist>
    <sha1/>
  </properties>
</project>

If you like to make a version this can simply being achieved by using this:

mvn -Drevision=2.0.0 clean package

Another usage example can be to make a release which can be done via (version 1.3.1):

mvn -Dchangelist= clean package

Or if you like to make a release with another version:

mvn -Drevision=2.7.8 -Dchangelist= clean package

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий