Build Systems - Local Repository

Continuation of the previous post about build systems - BuildSystems - Intro

Maven

An assembly system describing dependencies at different levels and plugins for performing tasks.
In the previous post there are links to other articles where this system is described, the distinguishing feature of which is the clearly defined assembly life cycle:

• validate - verifies the correctness of information about the project
• compile - compiles the sources, in fact this is an appeal to the plugin “compiler”;
• test - run unit tests
• package - package classes in the specified format (zip, rar, jar, war, ear, etc.)
• integration-test - launch integration tests after assembly
• verify - verifies the package’s correctness and quality requirements
• install - “install” an assembly to a local repository
• deploy - send the package to the specified server

Local Maven Repository

But none of these articles described what, in turn, was very useful for me - this is setting up a local repository.

By default, the following directory is used as the local repository (OS: Windows)

%userprofile%/.m2/repository 

But over time, the repository keeps growing and growing, and this fact, constantly filling the place on the system partition, began to disappoint me in direct proportion to the growth of the repository.
In addition, if suddenly you (like me) have several users configured with whom you work with, then two such duplicate repositories begin to upset twice as much.

To prevent this from happening, there is a good and elegant solution - to move the local repository to another section and configure all users to it.
To do this, open the file

 %userprofile%/.m2/settings.xml 

Where we add local repository settings

 <localRepository>E:/_MAVEN_LOCAL_REPOSITORY</localRepository> 

When using a local repository, the size of the ".m2" directory remains about 114Kb.

Plugin Usage

I also want to give a slightly advanced example of working with plugins for creating projects on archetype.
')
Creating a project for Eclipse

Call maven-eclipse-plugin

 mvn eclipse:eclipse 

Creating a project for IDEA

Call maven-idea-plugin

 mvn idea:idea 

But when you have these commands do not bring the desired result, you should look for help for the called plug-in, which can be called as follows:

 mvn <plugin_name>:help 

where the configuration and possible parameters for the plugin to which you are accessing will be described.

As for generation, you can request help on archetypes as follows:

 mvn archetype:generate 

Ant + Ivy

Ant is another build system
Ivy is a dependency manager that can access various repositories and find the necessary information in them and load it into a local repository (some cache, on a local machine).

Ant, in my opinion, gives a greater degree of freedom than Maven (in which, by the way, you can also access ant'a tasks / tasks), if only because you don’t need to automate one of the necessary stages of your build To do this, implement your own plugin for Maven. In other words, Ant is better suited to quickly automate certain actions to assemble your project and where any of your steps to the side will not be regarded as escaping and punished by execution.

The list of what was on Habré about this system (the most general) (read better, again, in the given order):

• Building Java applications using Apache Ant, quick start - description with examples of compilation and packaging tasks;
• Ant + Tomcat: a small routine automation is a good example of Ant + Tomcat integration and using assembly build tasks on the server, determining the server environment, starting / stopping the server, and even detecting memory leaks (find leaks);
• Managing dependencies in Android projects using Ivy - examples of using Ivy;
• A quick way to create an installer for a Java program is a great example of Ant's widespread use with a JavaFX connection.

Ivy local repository

A similar problem with locating and configuring the local Ivy repository, which by default is located in

 %userprofile%/.ivy2/cache 

The system configuration is read from “ivysettings.xml”, which can also be connected as follows:

 <ivy:settings file="${ivy.settings.file}" /> 

But the location of the local repository itself can be redefined in the “caches” section, specifying the “defaultCacheDir” attribute:

 <caches defaultCacheDir="${ivy.settings.cache}"> <cache name="cache"/> </caches> 

In this example, the previously set variable / property (property) “ivy.settings.cache” is used.

Conclusion

When getting acquainted with the assembly systems, you need to keep calm, remember that it was invented / written / implemented "to help". Therefore, if something objectively does not suit you, there must be a way to either reconfigure it or reduce your dissatisfaction to a minimum.