[Maven] Common commands, plug-in management, private server nexus
Common commands
MavenProvides a set of common commands for building, testing and managing projects. Here are some examples of commonly used Mavencommands:
mvn clean: Clears the generated output directories in the project (such as the target directory).
mvn compile: Compile the project source code.
mvn test: Run the project's unit tests.
mvn package: Packages the project, producing a distributable artifact (eg, JAR, WAR, or other format).
mvn install: Install project artifacts into the local Maven repository for use by other projects.
mvn deploy: Deploy project builds to a remote Maven repository for access and use by other developers.
mvn clean install: Clean the project and rebuild and install the project.
mvn dependency:tree: Displays the project's dependency tree, including all transitive dependencies.
mvn help:system: Display Maven system information.
mvn archetype:generate: Generate project skeleton according to Maven build template.
plugin management
In Maven, a plugin is an extension mechanism for providing additional build, test, deployment, and other project management functionality. Plugins can Mavenbe managed and configured through the plugin management system. Here are Mavensome common operations for plugin management:
Defining plugins: In your project's pom.xmlfiles, use <build>elements to define plugins. Add the configuration of the plug-in in <plugins>the element, including plug-in coordinates, execution targets, configuration parameters, etc.
Integrated plugins: MavenThere are some commonly used built-in plugins, such as maven-compiler-plugin, maven-surefire-pluginetc. These plugins can be configured pom.xmlvia <plugins>elements directly in the project's files, with no additional steps required.
Custom plugins: In addition to using built-in plugins, you can also write your own plugins. MavenUse Apache Mavenplugins （Apache Maven Plugin Plugin）to create and manage plugin projects. A skeleton that can be used Maven Archetypeto generate plugin projects.
Life cycle binding: MavenPlug-ins can Mavenbe bound to the life cycle. By configuring <executions>elements for plugins, it is possible to bind the plugin's execution goals to specific build phases, such as compilation, testing, packaging, etc.
Plug-in version management: specify the plug-in version <build>in the element of the project, and the version of the plug-in can be managed uniformly. <pluginManagement>This ensures that all modules use the same version of the plugin, improving build consistency and maintainability.
Run Plugin: mvn plugin-name:goalExecutes the goal of the plugin by running the command. For example, mvn clean, mvn compile, mvn test, mvn packageetc. are all predefined targets for running plugins.
Plug-in configuration: Use <configuration>the element to configure the plug-in in detail. It can be configured in the project pom.xmlfile according to the needs of the plug-in to meet the specific construction requirements.
MavenThe core only defines the abstract life cycle, and the specific tasks are all completed by the plug-in. Each plug-in can implement multiple functions, and each function is a plug-in target. The lifecycle of a plugin is bound to a plugin target to complete a specific build task. For example: is a target of the plugin
Maven
compilemaven-compiler-plugin
MavenIt is actually a framework that relies on plugins to execute, and each task is actually completed by plugins.
private server nexus
Nexus3
Nexus3 is a repository manager that greatly simplifies the maintenance of local internal repositories and access to external repositories.
Usually when we obtain maven warehouse resources, we always obtain them from the official maven (or domestic mirror image), but this is not the best solution. If in the same environment, multiple developers of a team rely on the same It has to be obtained remotely, which is very time-consuming from the network point of view. At this time, it is necessary to deploy a Nexus3 in the LAN to manage the Maven (apt, yum, gradle, pypi, docker, etc.) warehouse.
Some companies do not provide extranet to project team personnel, so maven cannot be used to access remote warehouse addresses, so it is necessary to find a machine with extranet permissions in the LAN, set up a Nexus3 private server, and then connect developers to this In this way, you can access the remote warehouse of maven through this computer with Nexus3 private server.
Configure private server
The configuration required to publish the jar to the private server
<servers>
<!-- 发布版 -->
<server>
<id>releases</id>
<username>admin</username>
<password>admin123</password>
</server>
<!-- 快照版 -->
<server>
<id>snapshots</id>
<username>admin</username>
<password>admin123</password>
</server>
</servers>
Download the configuration required for the private server warehouse jar
<mirrors>
<mirror>
<id>nexus</id>
<mirrorOf>*</mirrorOf>
<name>nexus maven</name>
<url>http://127.0.0.1:8081/repository/maven-public/</url>
</mirror>
</mirrors>
Configuration in the project pom
Prepare a maven project and add a configuration to pom.xml:
<distributionManagement>
<repository>
<id>releases</id>
<name>maven-releases</name>
<url>http://127.0.0.1:8081/repository/maven-releases/</url>
<uniqueVersion>true</uniqueVersion>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>maven-snapshots</name>
<url>http://127.0.0.1:8081/repository/maven-snapshots/</url>
<uniqueVersion>true</uniqueVersion>
</snapshotRepository>
</distributionManagement>
Distinguish between the official version and the snapshot version when releasing
To publish, just execute the command mvn deploy.
Two warehouses are configured here, one official version and one snapshot version. How does maven distinguish which warehouse you want to publish to?
If your version comes with releases, that is <version>0.0.1-releases</version>, it will be published to maven-releases.
If your version comes with snapshots, that is <version>0.0.1-snapshots</version>, it will be published to maven-snapshots.