Maven from entry to give up

What 1.maven that?

maven is a pure java development of an open source project under the Apache, which is an abstract can build process, and provides dependency management, central warehouses, and other functions are automatically downloaded to build the project build tool.

2. Why do you want to build the project using maven tool?

If we develop two Java project, temporarily called A, B, two projects for the case of some of the special features will be dependent on each other, how to do a good correlation between the two? It is intended to share a set of code A, B on both sides for connection? (This approach will be very difficult to maintain the late)

Whether we will share the code if packaged into a jar introduced used in the project, then the post-update code words but also on the jar all incoming update it? This approach seems to be very cumbersome.

Back before doing development, because of technology maven has not yet appeared, using ssh framework for the development of the time, all the jar need to artificially unified import and maintenance, resulting in the latter part of maintenance extremely difficult.

The maven you can solve the above mentioned problems.

How 3.maven jar will be managing it?

In this tool maven inside, there is a special concept called coordinates . This is not our mathematical coordinates which said that coordinates, but the set did a little math and coordinate similar is that each will have a unique identification coordinates of its own. In maven there is no exception:

    <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
            <version>1.2.47</version>
        </dependency>

 

For example, coordinate information on top of this, groupId often used to identify the actual project belongs to the jar, usually due to a project may be divided into a number of modules, it is therefore artifactId a clear identity for a module of the project . More version element is the definition of a real version of the component. We usually call this period of dependency as a dependent.

For read-dependent configuration also called scope

Classification scope of	explain
compile	By default, that is, compile type, This means that not only rely on the compiler to participate but also to participate in other aspects of post-test
test	It indicates that relies solely related to work and test
provided	Can participate in the cycle compile, test, operation, etc., But when packaged will operate accordingly exclude, and Other aspects and compile little difference
runntime	In compiling links will not be involved, not personal feelings and compile difference
system	Refers generally depend not read from the warehouse, but read by a local path-dependent, So often used in combination with labels systemPath

Of course, if we all make the appropriate settings for each individual version dependent, so it will be somewhat cumbersome management, so you can use a unified management or label, for example, the two sets of cases below:

Based parent dependency management:

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.4.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

 

Based dependency management properties, the properties in which we can be unified management of the entire character set encoding for some project or dependent jar package version number of unification of management:

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>
        <lombok.version>1.16.6</lombok.version>
        <aspectj.version>1.8.11</aspectj.version>
        <common.version>3.4</common.version>
        <codec.version>1.10</codec.version>
        <swagger2.version>2.7.0</swagger2.version>
        <mybatis.version>3.3.0</mybatis.version>
        <mybatis-spring-boot.version>1.3.1</mybatis-spring-boot.version>
        <pagehelper.version>1.2.3</pagehelper.version>
        <springfox-swagger-ui.version>2.7.0</springfox-swagger-ui.version>
        <mysql.version>5.1.6</mysql.version>
        <mongodb.version>3.2.2</mongodb.version>
    </properties>

 

4.maven warehouse

So when we rely on the corresponding project into the inside, what will happened?

internal maven will have a download from the Internet side dependent function, we usually say that you have a dependency jar platform for warehouse .

Inside the warehouse is divided into several maven: local warehouse, third-party warehouse, central warehouse

Are usually downloaded from the jar will exist on the developer computer local repository , the default address is  / repository $ user.home / .m2 directory under:

There is a lot of storage they have downloaded the jar, the second request when the central warehouse so you can avoid future re-use the same jar.

中央仓库是指maven官方自己维护的一个远程公用仓库：

http://repo1.maven.org/maven2 在这里面提供了丰富的jar包供开发人员进行下载使用。有时候我们在开发中会遇见下载jar包网速过慢的情况，这个时候可以尝试将mirrors配置修改为访问阿里云镜像的配置：

<mirror>
    <id>alimaven</id>
     <name>aliyun maven</name>
     <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
     <mirrorOf>central</mirrorOf>
</mirror> 

 

第三方仓库通常是指公司自己内部搭建的公共类库站点，只提供给公司内部共享服务所使用，通常都是搭建在局域网内部使用，而且对于内部私服的连接，通常公司都会有相关的账号密码进行控制。

Nexus就是一款较为强大的Maven仓库管理工具，它极大地简化了自己内部仓库的维护和外部仓库的访问。利用Nexus你可以只在一个地方就能够完全控制访问 和部署在你所维护仓库中的每个Artifact。

Nexus是一套“开箱即用”的系统不需要数据库，它使用文件系统加Lucene来组织数据。Nexus 使用ExtJS来开发界面，利用Restlet来提供完整的REST APIs，通过m2eclipse与Eclipse集成使用。Nexus支持WebDAV与LDAP安全身份认证。

除了Nexus以外，还有挺多知名的仓库管理工具，例如说JFrog Artifactory

 

5.maven工程的项目结构是如何的呢？

在idea编译器里面，对于maven工程的创建时候，默认的结构通常都是如下所示：

在开发的时候，通常代码编写都是在main文件夹底下进行，而如果需要编写相应的测试代码则在test目录底下进行，java目录下一般是放置我们的代码内容，resources目录底下更多的是存放一些我们的配置文件，例如说xml，yml，properties这类型的文件内容。

当然如果是创建maven-web结构的工程的话，可以在建立maven工程的时候选择相应的构建模板：

项目结构如下所示：（可能idea版本不同，最终的成效截图会有所出入）

 

当然，现在的项目大多都是基于父子工程的偏多，maven里面也支持这种工程的搭建，通常我们可以事先构建好一个父工程结构，然后再在父工程的基础上边构建相应的module工程。例如下边的工程截图：

 

6.maven的常用命令和生命周期

其实maven它本身是具有三套独立的生命周期的，这三套的生命周期分别是clean，default，site，分别有着不同的职责：清理，构建，建立站点

maven的三套生命周期之间实质上是需要互相依赖的，通常都是后者依赖于前者的关系，以clean生命周期为例，它包含的阶段有pre-clean、clean和post-clean。

 

当用户调用pre-clean的时候，只有pre-clean阶段得以执行；当用户调用clean的时候，pre-clean和clean阶段会得以顺序执行；当用户调用post-clean的时候，pre-clean、clean和post-clean会得以顺序执行。

maven之所以将整个项目的阶段划分得如此细致，我个人的观点是这种细粒度的划分更加地利于工程构建过程中的排查错误，不同的环节由不同的插件来负责这一模块，当抛出了异常报错，我们就只需要对该环节进行分析，例如编译出错，打包出错等。

maven自身提供了非常多的命令供我们使用，下边列举了我们常用的命令基本如下：

• mvn archetype:create ：创建 Maven 项目 

• mvn compile ：编译源代码 

• mvn test-compile ：编译测试代码 

• mvn test ： 运行应用程序中的单元测试 

• mvn site ： 生成项目相关信息的网站 

• mvn clean ：清除目标目录中的生成结果 

• mvn package ： 依据项目生成 jar 文件 

• mvn install ：在本地 Repository 中安装 jar

7.通过profile文件来指定特定的编译环境

在实际的项目开发过程中，我们通常会需要结合实际的应用场合切换不同的运行环境（dev，test，pre，pro）,在不同的环境中我们通常需要读取不同的配置文件，例如不同的数据源配置，端口号配置等。

如果每次切换环境的时候都要开发人员进行相关的手动修改配置的方式来进行的话，那么实际的工作效率会显得较低，不妨可以试试使用pom里面提供的profile配置：

<profiles>
    <profile>
        <!-- 本地开发环境 -->
        <id>dev</id>
        <properties>
            <profiles.active>dev</profiles.active>
        </properties>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
    </profile>
    <profile>
        <!-- 测试环境 -->
        <id>test</id>
        <properties>
            <profiles.active>test</profiles.active>
        </properties>
    </profile>
    <profile>
        <!-- 生产环境 -->
        <id>pro</id>
        <properties>
            <profiles.active>pro</profiles.active>
        </properties>
    </profile>
</profiles>

 

After the contents of the corresponding profile in the configuration file inside pom above, when performing packing works default read mode is determined by different environments (corresponding to the profile file id) manner mvn clean package -Pdev.

So that we can concentrate more on the code development work, based on this idea, we can achieve different environments through automated packaging functions corresponding scripting.