手把手教你完成比赛之什么是Maven?

Maven 的原理简介


Maven目前是主流的项目管理工具，提到项目管理，大家似乎就会觉得，高大上啊？这是什么玩意儿啊？ 跟我有什么关系啊？等等，别急别急，下面就由我来给大家做一个介绍。


Maven的作用


Maven是我觉得到公司以后，发现最能够帮助我的一套工具（比git/svn对我的帮助还要大）。
在我们的日常开发中，经常需要引入一些依赖包，他们会通过So包/Jar包等方式引入到我们的项目中。
想必很多人碰到这种情况，第一印象就是把这个依赖包拷贝到我们的某个lib目录下面，然后在配置里面指定一下依赖关系，就可以使用了。
看起来，这种方式似乎可以工作，看起来也很简单，那我们就这样继续的愉快玩下去不就好了？


且慢~


让我们看看这些场景：
如果我们有一个10人的团队，团队内都需要一些相同的依赖包，这时候你发现：”这程序在别人那能跑，在我这怎么不行了？ “你会怎么排查一下？ --- 最后发现是有个人多引入了一个包，结果这个包你没有引入 。。。
项目要引入50个包，都放在svn上？--- Svn/git的管理员要骂娘了
我的项目要开源，git服务器远在国外，每次都把lib上传下载，都够抽10根儿烟的了。 -- 项目复制代价高
别人那里有个包，名字跟我这完全一样，结果我这里就挂了，他那边就没有，这是为啥 --- 人家这个包是从新打出来的，忘记上传了。。


好了，碰到这些场景，选择Maven 就一定是没错的了~


Maven这个项目最开始就是一个项目包依赖的管理工具，从这个项目包依赖工具往外延伸，就是项目结构的管理工具。
Maven 原理与操作实践


他能够给我们带来的最大便利，就是把项目依赖的包+版本，利用配置文件管理起来，将项目与依赖进行了分离


所有的包依赖，都被抽象为一个包的名字加一个包的版本，这两个东西会唯一的定位到一个包，并且这个对应好的包在原则上是不能修改的。那么如果包更新了怎么办呢？ 那就增加版本号，创建新的连接。


因为利用这种方式，我们就从一定程度上规避了项目包管理中的各种不规范问题，让我们进行项目依赖管理变得非常便利。


目前，maven基本上已经成为了java代码的标配工具，所以在各种ide中都集成了Maven工具，基本可以完全脱离命令行使用


Maven的基本结构


Maven有个基本的目录结构，这个目录结构是maven管理项目的标准化目录（改变这些目录的名字，maven就不能识别这些目录啦）


我们一起来看看：



这些目录里面，最应该关注的是这么几个：
main/java : 这里会存放主要的业务java代码
main/resources: 这里存放业务的配置文件


test/java : 这是存放测试代码的部分（打包的时候test不会被打到包内），这些代码只在测试时有效。
test/resources : 测试代码所需的配置文件（也不会被打包到包内）
pom.xml 这就是关键的配置文件了。


我们再进入到maven的pom.xml文件里面看看



首先这三行
<groupId>com.alibaba.middleware.race</groupId>
<artifactId>rpc_test</artifactId>
<version>1.0-SNAPSHOT</version>


表述的是我自己的这个项目的项目名字和版本，当我们打包的时候，项目名字和版本也会作为我们这个jar包的项目名+版本，被发布到maven服务器中。被其他人依赖。


<dependencies>
       <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.4</version>
           <scope>test</scope>
    </dependency>
</dependencies>


这几行，表述了一个依赖， 依赖了junit.junit这个包，版本是4.4.
这样，maven就可以从自己的中心服务器里面，根据junit.junit:4.4 这个名字，去找他对应的依赖jar包，下载下来并作为项目的依赖包引入。


<build>
        <finalName>rpc-api</finalName>
        <sourceDirectory>src/main/java</sourceDirectory>
</build>
这一段，表述的是一个项目在打包期要做的事。 他会把src/main/java下面的包，在打包的时候变成rpc-api.jar