Maven - build automation project

For a long time I heard about the tool for automating the assembly of the project - Ant , but somehow I could not find him a real use in PHP projects. You don't need to compile anything, you can easily connect external libraries via svn:externals , there were only tests that were freely executed via $ phpunit AllTests.php , and the transfer of changes to the $ phpunit AllTests.php server ( svn export + small self-written script). Even a fairly good article about using ant in eclipse did not make me use this tool, and I didn’t want to write any build files either ...

In general, everything is as usual. It would seem that some such thing would not hurt, but everything worked so well and was too lazy to learn pseudo-assisted technology. That was until I became acquainted with Java ...


With the arrival of Java in my life, a glance at the question of whether to use the automatic builder has disappeared by itself - to use. After all, what kind of freak will manually compile all the files in all the project directories and copy them for deployment to the servlet container directory? Only a very patient and not lazy person. But laziness is the engine of progress, and I began to read about ... maven .
')
I do not even know how he turned up. Probably after one of the queries in Google in the process of learning the basics of tomcat, I got knowledge of the existence of this program. Already the fourth Apache product that I needed on my way to deploying the first java project.

Maven combines ant capabilities (build and copy files, conduct tests), but besides this it helps to solve dependencies of project libraries, has a completely formal lifecycle, has many plug-ins and takes all the same three characters in the command line: mvn vs ant .

The life cycle of the maven is quite expected:

• validate - validates project metadata
• compile - compiles sources
• test - runs class tests from the previous step
• package - packs compiled classes in a conveniently movable format (jar or war, for example)
• integration-test - sends packed classes to the integration testing environment and runs tests
• verify - verifies the package’s correctness and quality requirements
• install - pushes the package to the local repository, from where it (pec) will be available for use as a dependency in other projects
• deploy - sends the package to a remote production server, from where other developers can get it and use it

In this case, all the steps are consistent. And if, for example, you run $ mvn package , then the steps will actually be executed: validate, compile, test, and package. Thus, using maven is quite simple. You wrote the code, executed the mvn test and you can continue to work, making sure that the code does not contain syntax and logical errors.

Separately, it is worth mentioning dependencies. Maven is configured by the pom.xml file, which can contain the <dependencies /> block. It describes which libraries the project needs for full operation. At the validate step, the maven checks whether the dependencies are satisfied and, if not, downloads the necessary components from the remote repository to the local repository. So, if 10 projects depend on the same SomeSpecificOrm library, then we no longer need to connect it in 10 places via svn:external , especially if the library takes up enough space, but it is enough to specify it in the dependency file and it will be taken from the local repository mavena. When specifying dependencies, you can specify not only the library name, but also its version - in this way there will be no problems with backward compatibility.

And now we come directly to the question “what does maven do for web development”. In addition to compiling, testing and packaging, maven allows you to deploy a project in tomcat using the tomcat-maven-plugin . It is configured in pom.xml and has approximately the following form:

 [...]
 <plugins>
     <plugin>
    	 <groupid> org.codehaus.mojo </ groupid>
    	 <artifactid> tomcat-maven-plugin </ artifactid>
    	 <version> 1.0-beta-1 </ version>
    	 <configuration>
    	     <path> / </ path>
    	     <url> http: //site.local: 8080 / manager </ url>
    	     <server> site.local </ server>
    	 </ configuration>
     </ plugin>
 </ plugins>
 [...]

The configuration requires a little explanation. So path is responsible for the path to which the servlet will be deployed. Since we are deploying a fully-fledged, self-contained web application, we will deploy to /. Url points to the path to the host manager, through which we will be deployed. A manager servlet is usually created during the creation of a new virtual host . Server specifies the server id. Here you need to go deeper into the explanation ...

As for deployment through the host manager, you need to go through authorization, and specifying data for a login in the configuration file is not the most correct solution, since the data can be changed from server to server, so the pointer by id is used. The authorization data itself is configured in the ~/.m2/settings.xml file in the servers section. So my section looks like this:

 [...]
 <servers>
     <server>
         <id> site.local </ id>
         <username> manager </ username>
         <password> manager </ password>
     </ server>
 </ servers>
 [...]

username and password must match the user with manager rights from the tomcat-users.xml (see the previous article on servlets for more details).

Now in order to send the project to the servlet container, all you need to do is: $ mvn tomcat:deploy and maven take care of compiling, testing, packaging and deploying the project. It will only update the browser page to see the changes.

Yes. Finally, I want to say that maven also dictates its own hierarchy of directories, but in order not to create it manually, just run:

 $ mvn archetype: create \
   -DarchetypeGroupId = org.apache.maven.archetypes \
   -DgroupId = com.mycompany.app \
   -DartifactId = my-app

And for eclipse there is a special plugin that will simplify the creation and maintenance of the project.

PS I understand that the material was not fully disclosed, so if some points remained completely unclear or simply not complete - write, and I will supplement the article.

PPS in the original article is still a small survey, in which, for the most part, developers of PHP are invited, while the rest are invited by interest.