Everything you wanted to know about Maven. (Part 2) - "Java project from A to Z"

All about Maven: the beginning I love to practice. You can’t even imagine how tedious it can sometimes be to write about theory. However, you can’t go anywhere without her. Practice is another matter, of course. Now let’s quickly go through the commands that I previously described, and we’ll finish)

Setting up pom.xml

While we were theorizing, we got a pretty good pom.xml:

View code

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns="http://maven.apache.org/POM/4.0.0"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                     http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>

   <groupId>com.github.javarushcommunity</groupId>
   <artifactId>maven-demo</artifactId>
   <version>1.0-SNAPSHOT</version>
   <packaging>jar</packaging>

   <name>Maven Demo Project</name>

   <url>https://github.com/javarushcommunity/maven-demo/</url>

   <licenses>
       <license>
           <name>The Apache Software License, Version 2.0</name>
           <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
       </license>
   </licenses>

   <developers>
       <developer>
           <id>romankh3</id>
           <name>Roman Beskrovnyi</name>
           <email>roman.beskrovnyy@gmail.com</email>
       </developer>
   </developers>

   <scm>
       <connection>git@github.com:javarushcommunity/maven-demo.git</connection>
       <developerConnection>git@github.com:javarushcommunity/maven-demo.git</developerConnection>
       <url>https://github.com/javarushcommunity/maven-demo</url>
   </scm>

   <properties>
       <mockito.version>2.26.0</mockito.version>
       <junit.version>5.5.2</junit.version>
       <image.comparison.version>4.3.0</image.comparison.version>
       <maven.compiler.source>1.8</maven.compiler.source>
       <maven.compiler.target>1.8</maven.compiler.target>
       <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
       <javadoc.plugin.version>3.1.1</javadoc.plugin.version>
       <source.plugin.version>3.2.0</source.plugin.version>
   </properties>

   <dependencies>
       <dependency>
           <groupId>org.mockito</groupId>
           <artifactId>mockito-core</artifactId>
           <version>${mockito.version}</version>
           <scope>test</scope>
       </dependency>
       <dependency>
           <groupId>org.junit.jupiter</groupId>
           <artifactId>junit-jupiter-api</artifactId>
           <version>${junit.version}</version>
           <scope>test</scope>
       </dependency>
       <dependency>
           <groupId>com.github.romankh3</groupId>
           <artifactId>image-comparison</artifactId>
           <version>${image.comparison.version}</version>
       </dependency>
   </dependencies>

   <build>
       <plugins>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-source-plugin</artifactId>
               <version>${source.plugin.version}</version>
               <executions>
                   <execution>
                       <id>attach-sources</id>
                       <goals>
                           <goal>jar</goal>
                       </goals>
                   </execution>
               </executions>
           </plugin>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-javadoc-plugin</artifactId>
               <version>${javadoc.plugin.version}</version>
               <executions>
                   <execution>
                       <id>attach-javadocs</id>
                       <goals>
                           <goal>jar</goal>
                       </goals>
                   </execution>
               </executions>
           </plugin>
       </plugins>
   </build>
</project>

- But in order to have something to compile, it needs to be added there! Logical? - Yes captain. bgg Therefore, let's add a class that will have a method and two tests for it. Let's create a regular folder scheme for Maven: In src/main/java we will create a package in which we will work. To compose it correctly, it would be good to put the name of the organization ( groupId ) at the beginning, and then the name of the project. In our case it will be like this: com.github.javarushcommunity.mavendemo As for me, this is a very good package. In it we will create the ImageComparator class , for which we will write two tests.

Connecting Maven and the project as a whole to IDEA

In order for the idea to be able to recognize our dependencies and offer to use them in the project, we need to do several things:

1. Tell the idea where the code sources will be and where the tests will be.
2. Add a maven project to the idea.

To achieve the first, you need to find this icon: Click on it and go to the Modules section . Next, you need to give the created folders the required marker, as shown in the figure below: That is:

• • src/main/java - Sources
• • src/main/resources - Resources
• • src/test/java - Tests
• • src/test/resources - Test Resources
• • target - Excluded

All these Sources, Resources, Test, Test Resources and Excluded can be found on the line where Mark as is written . Select a folder and label it accordingly. And the second step is to add the maven project to IDEA so that it can work its magic. To do this, you need to find the pom.xml file in IDEA and right-click to select Add as Maven Project . And that’s it, you will be happy (: After this, a Maven plate will appear on the right , which you can open and run Maven commands in it.

We write sources and tests for our “project”

So, we added Maven to the idea, now let’s describe the class that will act as sources for us:

ImageComparator:

package com.github.javarushcommunity.mavendemo;

import com.github.romankh3.image.comparison.ImageComparison;
import com.github.romankh3.image.comparison.model.ImageComparisonResult;
import com.github.romankh3.image.comparison.model.ImageComparisonState;

import java.awt.image.BufferedImage;

/**
* Class created for answering, does two images the same or not.
*/
public class ImageComparator {

   /**
    * Method, which says the same images or not.
    *
    * @param image1 image1 for comparison
    * @param image2 image2 for comparison
    * @return return true, if images are the same, false - otherwise.
    */
   public boolean isTheSameImages(BufferedImage image1, BufferedImage image2) {
       //Create ImageComparison object
       ImageComparison imageComparison = new ImageComparison(image1, image2);

       //Compare images
       ImageComparisonResult imageComparisonResult = imageComparison.compareImages();

       //Check, that ImageComparisonState is MATCH:
       return ImageComparisonState.MATCH == imageComparisonResult.getImageComparisonState();
   }
}

Let's create tests for this purpose. The class that tests must be in the same package, only in src/test/java. The idea knows this, and you can take advantage of its capabilities. To do this, click on the class name in the file itself and select Create test on the light bulb that appears: We will be asked to select settings for the future test. We don’t install anything, just click OK: For our test, we’ll take image-comparison from the test images and put them in test resources (src/test/resource). After this we will write two tests. One will check that these two pictures are different. And in the other we will transmit the same picture and expect an answer that they are the same. Then we get the following test:

package com.github.javarushcommunity.mavendemo;

import com.github.romankh3.image.comparison.ImageComparisonUtil;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

import java.awt.image.BufferedImage;

@DisplayName("Unit-level testing for ImageComparator")
class ImageComparatorTest {

   private final ImageComparator comparator = new ImageComparator();

   @Test
   public void shouldConfirmImagesNotTheSame() {
       //given
       BufferedImage image1 = ImageComparisonUtil.readImageFromResources("image1.png");
       BufferedImage image2 = ImageComparisonUtil.readImageFromResources("image2.png");

       //when
       boolean theSameImages = comparator.isTheSameImages(image1, image2);

       //then
       Assertions.assertFalse(theSameImages);
   }

   @Test
   public void shouldConfirmImagesTheSame() {
       //given
       BufferedImage image1 = ImageComparisonUtil.readImageFromResources("image1.png");

       //when
       boolean theSameImages = comparator.isTheSameImages(image1, image1);

       //then
       Assertions.assertTrue(theSameImages);
   }
}

The tests are very simple, I won’t dwell on them. If you are interested, I will write an article about testing someday (write about it in the comments).

Execute Maven commands

Now, when everything is ready to see the work of the teams, select our project in the Maven plugin and open Lifecycle in it : Now click compile and see what happened: From this we can draw two conclusions:

1. Our sources were compiled and placed in the specified path.
2. The command was successful - BUILD SUCCESS.

And really, if we go to the project structure and look at what has changed there, we will see that the target folder has been added , which we can still explore and find our compiled ImageComparator class : Now I would like to start a new package command from scratch. To do this, let's run (click twice) the clean command : As a result, we are told that we have deleted the target folder , which contained everything that was created after the compile command . Let's run the command test : Tests run: 0... but we wrote as many as TWO. That is, for some reason the tests did not run. Live coding is like that, let's go to the web) After 5 minutes of googling, I found that with JUnit5 you need to add one more plugin:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <version>2.22.2</version>
</plugin>

Let's add it to the project, put the version in <properties/> as best we can and restart test : Now it’s a different matter! Two tests ran and were successful. Fire! Now we run our package and expect that we will find the jarnik in the target folder: That is, we see again that the tests have passed, and after this (guarantees that everything in the project is good) we can collect the project into an archive. The figure shows that there is an archive in the maven launch logs and the project structure. Next we have install . Great team. Oh, before I forget. It is considered good practice to clean the project before executing a new command by running clean . This will save you from nonsense in the future - I guarantee it from my own experience))) Therefore, first we run clean , and then install : Where the arrow is, you can clearly see where the local repository is located. Based on what they write, this is on my way: /Users/roman_beskrovnyi/.m2 And the archive itself will be located here: /Users/roman_beskrovnyi/.m2/repository/com/github/javarushcommunity/maven-demo/1.0-SNAPSHOT And if we go to the terminal and try to get into the folder where the archive is located, then it will be there: deploy won’t show us, and you don’t need the others yet...

Instead of output

Today we quickly went through what Maven is, what is there, what are the main commands there. I tried to convey this simply and with examples. All source code for the example is located in the JavaRush Community organization on GitHub in the maven-demo project . Write all questions in the comments. As usual, I suggest you subscribe to my account on Github so as not to miss the new code for our JRTB project. Once again, he is not dead. He was simply in stasis))

A list of all materials in the series is at the beginning of this article.