Perfect maven. Part 1

I know he is not perfect, but at least I will try to tell you how to get him closer to this.

In one note, everything will not enter, so first a plan:

1. Task setting - description of the configuration of projects with which we will work, goals and problems
2. How to set up maven for development as part of our task
3. How to set up CI / CD (builds, releases, deployment)
4. Unsolved problems

Task

So, let's start with the problem statement. Suppose we have a group of people (company, firm, circle) who develop projects in Java. At the same time, they have both open source projects (OSS) and closed-source projects. Projects, let's call them internal, are developed independently of each other, but there are dependencies between them. What do you want:

• Centralized dependency management on external libraries
• OSS projects in the central maven repository
• Closed projects in your maven repository.
• "Simple" release of internal projects with updating dependencies in dependent projects.
• Maximum automation of all hotelok.

It is important to understand that we will be together to solve these problems; therefore, without implementing all the requests, the system will not work at all or will be, but not in full force.

I also want to say that everything written below is my personal opinion, I realize that you can customize the maven in different ways, and for my part I really hope to find something new in the discussion of this article that will help to make the existing model even better. In my defense, I can say that the model that I will describe is already working, and not one year. The open part lies on BitBucket, in particular, here .

Customize maven

Centralized dependency management on external libraries

To manage third-party dependencies, mavena has a special dependencyManagement section and an inheritance mechanism. It would seem that this is the answer, we are doing a “corporate” POM and inheriting from it the root POMs of all our projects. Yes, it will, but here are the details ... So, here it is our future "corporate" POM:

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.team</groupId> <artifactId>org.team.pom</artifactId> <version>0-SNAPSHOT</version> <packaging>pom</packaging> <properties> <spring.version>4.3.12.RELEASE</spring.version> <junit.ver>4.12</junit.ver> </properties> <dependencyManagement> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-framework-bom</artifactId> <version>${spring.version}</version> <type>pom</type> <scope>import</scope> </dependency> <!-- Exclude commons-logging from whole Spring --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${spring.version}</version> <exclusions> <exclusion> <artifactId>commons-logging</artifactId> <groupId>commons-logging</groupId> </exclusion> </exclusions> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${junit.ver}</version> <scope>test</scope> </dependency> </dependencies> </dependencyManagement> <build> <pluginManagement> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>3.7.0</version> <configuration> `<source>1.8</source> <target>1.8</target> </configuration> </plugin> <plugin> <artifactId>maven-deploy-plugin</artifactId> <version>2.8.2</version> </plugin> <plugin> <artifactId>maven-surefire-plugin</artifactId> <version>2.20.1</version> </plugin> <plugin> <artifactId>maven-war-plugin</artifactId> <version>3.2.0</version> </plugin> <plugin> <artifactId>maven-clean-plugin</artifactId> <version>3.0.0</version> </plugin> <plugin> <artifactId>maven-install-plugin</artifactId> <version>2.5.2</version> </plugin> <plugin> <artifactId>maven-site-plugin</artifactId> <version>3.5.1</version> </plugin> <plugin> <artifactId>maven-jar-plugin</artifactId> <version>3.0.2</version> </plugin> <plugin> <artifactId>maven-resources-plugin</artifactId> <version>3.0.2</version> </plugin> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>3.1.0</version> </plugin> </plugins> </pluginManagement> </build> </project> 

Everything is standard, but I want to pay attention not to some things:

• Will copy, remove the apostrophe on in the maven-compiler-plugin configuration. It is there so that the local editor would not replace <source> with three apostrophes.
• This is not the final version, but the minimum version, which we will write in the following sections.
• Versions of all components are in the variables section. For 2-3 dependencies, it does not matter, but when you have 50 of them and the dependencyManagement section takes up several screens, this makes it easier to update versions.
• In addition to the versions themselves, in the dependencyManagement section, you can override the scope of use (sope) dependencies and remove some transitive dependencies. This opportunity is better not to abuse and always write comments why and why it is so done.
• Also in our POM'e present section pluginManagement. Its role is about the same - centralized management of plug-ins used to build the project. Why is it important? By default, maven uses the latest available plug-in versions. So, the build from the same sources now and in a year may differ or simply not pass. With the help of this section, we fix plug-in versions, which, according to the idea, minimizes possible differences.
• Another possibility is to define common configuration parameters for plugins - for example, the bytecode version that we use in all our projects.
• And not a very significant point, until we reached the releases, this is the version of our POM. I wrote it as 0-SNAPSHOT . In fact, it is important that it be any SNAPSHOT. We will not change it in the future. Why, I will tell in the following articles.

What problems / misunderstandings do you usually encounter when using a “corporate” POM?

• It is not clear how to make releases (not necessary)
• Do I need to include separate projects as modules (not necessary)
• Is it necessary to describe the versions of internal projects in the “corporate” POM (not necessary)
• How to track and how often update versions of external libraries
• Failure to understand the difference between the “corporate” and root POM of an individual project

All this we will analyze in the following parts of this article. I’ll briefly discuss the last two points.

The difference between the “corporate” POM and the root POM of an individual project

A “corporate” POM describes the general rules for all your projects in a company — such as Java version, dependencies and their versions, general restrictions on projects that mavens can follow, contacts to developers, etc. In a “corporate” POM, there should be no information (“dependencies”) about specific internal projects — their versions, specific profiles, and similar things.

How to track and how often update versions of external libraries

Versions of libraries / plugins can be easily tracked using the maven itself ( versions-maven-plugin plugin ). To do this, add the following fragment to our pluginManagement section in our “corporate” POM.

 <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>versions-maven-plugin</artifactId> <version>2.5</version> <configuration> <rulesUri>file://${user.dir}/rules.xml</rulesUri> <generateBackupPoms>false</generateBackupPoms> </configuration> </plugin> 

Next to pom.xml, create a rules.xml file with the following contents

 <ruleset comparisonMethod="maven" xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd"> <ignoreVersions> <ignoreVersion type="regex">.*-does-not-exist</ignoreVersion> <ignoreVersion type="regex">.*[Aa]lpha.*</ignoreVersion> <ignoreVersion type="regex">.*(?i)beta.*</ignoreVersion> <ignoreVersion type="regex">.*pre.*</ignoreVersion> <ignoreVersion type="regex">.*[Dd]raft.*</ignoreVersion> <ignoreVersion type="regex">.*-rc.*</ignoreVersion> <ignoreVersion type="regex">20041228\.180559</ignoreVersion> <ignoreVersion type="regex">.*jbossorg.*</ignoreVersion> <ignoreVersion type="regex">.*dev.*</ignoreVersion> <ignoreVersion type="regex">\d+\.\d+</ignoreVersion> <ignoreVersion type="regex">.*(19|20)\d\d(0[1-9]|1[012])(0[1-9]|[12][0-9]|3[01]).*</ignoreVersion> <ignoreVersion type="regex">.*jboss.*</ignoreVersion> <ignoreVersion type="regex">.*atlassian.*</ignoreVersion> <ignoreVersion type="regex">.*xwiki.*</ignoreVersion> <ignoreVersion type="regex">.*b\d\d</ignoreVersion> <ignoreVersion type="regex">.*_ALPHA</ignoreVersion> <ignoreVersion type="regex">.*M\d</ignoreVersion> <ignoreVersion type="regex">.*RC\d</ignoreVersion> <ignoreVersion type="regex">.*\.jre7</ignoreVersion> <ignoreVersion type="regex">.*\.jre6</ignoreVersion> <ignoreVersion type="regex">.*CR\d</ignoreVersion> <ignoreVersion type="regex">.*M\d*</ignoreVersion> <ignoreVersion type="regex">.*pr\d</ignoreVersion> <ignoreVersion type="regex">.*android</ignoreVersion> <ignoreVersion type="regex">.*m\d*</ignoreVersion> <ignoreVersion type="regex">.*p\d*</ignoreVersion> </ignoreVersions> </ruleset> 

In principle, this is not necessary, and the line <rulesUri>file://${user.dir}/rules.xml</rulesUri> can be removed. I have this file is used to filter the various "junk" version which I prefer to ignore.
After that, just run the versions:display-dependency-updates and versions:display-plugin-updates and get the results:

 [INFO] The following dependencies in Dependency Management have newer versions: [INFO] com.amazonaws:aws-java-sdk-core ................. 1.11.221 -> 1.11.237 [INFO] com.amazonaws:aws-java-sdk-dynamodb ............. 1.11.221 -> 1.11.237 [INFO] com.amazonaws:aws-lambda-java-core .................... 1.1.0 -> 1.2.0 [INFO] com.amazonaws:aws-lambda-java-events .................. 2.0.1 -> 2.0.2 [INFO] com.google.guava:guava .......................... 23.3-jre -> 23.5-jre [INFO] com.google.guava:guava-gwt ...................... 23.3-jre -> 23.5-jre [INFO] com.google.inject:guice ................................. 3.0 -> 4.1.0 [INFO] io.sentry:sentry-logback .............................. 1.6.1 -> 1.6.3 

 [INFO] The following plugin updates are available: [INFO] org.codehaus.mojo:sonar-maven-plugin ......... 3.3.0.603 -> 3.4.0.905 [INFO] [INFO] All plugins have a version specified. 

By the way, the second team will warn you if you are using some kind of plugin without specifying its version (though for this you need to run it on project POMs)

In short, this is all about the "corporate" POM. In the next part, I plan to talk about the typical structure of the project and, possibly, about the organization of the deposit of artifacts in the central and corporate repositories.