Maven是Java世界中一个很好使的项目管理工具,关于【好使】这个特性从项目的使用量上就能体现出来,虽然说现在有更好使的Gradle,但是Maven的地位也不会那么轻易被撼动,支持者还是多多。
Maven的产生背景
在学习一个新知识之前,应该要以历史的眼光来看待这个技术出现的原因,以及这个技术解决的问题,也就是背景,这样能更好地理解这个技术。
在没有Maven之前,开发一个项目,当需要用到别人写的代码的时候,基本上是这样的:
1.开发一个项目,当需要用到别人写好的jar包,就需要把开源的jar包下载下来放到项目的lib目录下,并且根据这个目录添加到CLASSPATH中,以此来告诉Java执行环境,在哪些目录下可以找到要执行的Java程序需要的类或者包。
2.当下载了aa.jar包之后,发现还需要依赖bb.jar包,于是就去下载bb.jar包,重复步骤直到下载并添加完所有需要的jar包。
3.如果运气好,项目在添加完所有的依赖之后就能够正常运行了。但是如果运气差的话,就会遇到版本的问题,比如aa.jar包在调用bb.jar包的时候发现bb.jar包中根本没有需要的方法,这个方法只存在在bb.jar包别的版本中,那么这样的话,就需要花不少的时间在查找依赖和适配版本的jar包上了。
4.另外的,往git或者svn上提交代码的时候,还必须要把这些lib都上传上去,否则别人就要重复你前面做过的所有查找和添加依赖的操作。同样的,别人下载你的代码也是要把完整的lib下载下来。这样,不仅会浪费代码版本管理的时间,代码版本管理的空间,还会提高的开发的时间成本和降低开发的效率。
这时候Maven作为Java世界中的包管理工具就应运而生。就好像Linux世界中的yum、Web前端世界中的webpack一样,是一种方便开发者管理各种依赖的包管理工具。
Maven仓库的种类
Maven查找jar包的过程是这样的:先在本地仓库找;找不到的话,就去私服找(如果配置了私服的话);再找不到,就到中央仓库去找(默认的中央仓库是http://repo1.maven.org/maven2/,由Maven团队负责维护)。
最后如果在中央仓库找到之后,就会在私服和本地仓库都放一份,从私服找到之后也会在本地仓库放一份,这样下次再查找依赖就不需要到中央仓库去下载了。
关于仓库的配置,当你安装(Windows下一般是解压和配置环境变量)好了Maven之后,Maven的安装目录在conf目录下会有一个settings.xml配置文件,这个配置文件中提供了很多的配置项,其中就有配置仓库的配置项,包括本地仓库、私服和中央仓库的配置。
关于私服首先要搭建私服,比较繁琐,需要用另外的篇幅来记录,因此这里就略过私服的配置,只提及本地仓库和中央仓库的配置。
本地仓库的配置是通过localRepository标签配置的:
<!-- localRepository | The path to the local repository maven will use to store artifacts. | | Default: ${user.home}/.m2/repository --> <localRepository>D:\maven_repo</localRepository>
中央仓库的配置是通过mirrors-mirror标签配置的(这里设置为淘宝镜像):
<mirrors> <!-- mirror | Specifies a repository mirror site to use instead of a given repository. The repository that | this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used | for inheritance and direct lookup purposes, and must be unique across the set of mirrors. | <mirror> <id>mirrorId</id> <mirrorOf>repositoryId</mirrorOf> <name>Human Readable Name for this Mirror.</name> <url>http://my.repository.com/repo/path</url> </mirror> --> <mirror> <id>nexus-aliyun</id> <mirrorOf>central</mirrorOf> <name>Nexus aliyun</name> <url>http://maven.aliyun.com/nexus/content/groups/public</url> </mirror> </mirrors>
需要注意的是,这些配置项如果不进行配置的话,Maven是提供有默认值的,默认值都在注释掉的配置项中。
在自身的属性配置这一点上,Maven都贯彻了【约定优于配置】的理念,真的是优秀啊。
Maven项目的整体结构
Maven遵循的原则是【约定优于配置】,因此使用Maven构建的项目的默认结构是下图这样的:
1.Maven默认配置了${project.basedir}/src/main/java为项目的源代码目录。
2.Maven默认配置了${project.basedir}/src/main/test为项目的测试代码目录。
3.Maven默认配置了${project.basedir}/target为项目的编译输出目录等。
。。。
当然了,既然说是默认配置,当然是可以修改的,可以在项目的pom.xml的build标签中修改这些源代码目录,只是一般不建议改,一般人也不会去改。
<build> <sourceDirectory>src/java</sourceDirectory> <testSourceDirectory>src/test</testSourceDirectory> <outputDirectory>output/classes</outputDirectory> <testOutputDirectory>output/test-classes</testOutputDirectory> <directory>target/jar</directory> </build>
Maven项目结构的特殊性是由【约定优于配置】的特性来决定的,这一特性减少了很多不必要的配置,是使之打败前辈Ant的主要原因之一。
Maven管理工具的目录结构
下图是Maven管理工具的目录结构。
bin目录:该目录包含了mvn运行的脚本,这些脚本用来配置Java命令,准备好CLASSPATH和相关的Java系统属性,然后执行Java命令。
boot目录:该目录只包含一个文件,该文件为plexus-classworlds-2.5.2.jar。plexus-classworlds是一个类加载器框架,相对于默认的Java类加载器,它提供了更加丰富的语法以方便配置,Maven使用该框架加载自己的类库。
conf目录:该目录包含了一个非常重要的文件settings.xml。直接修改该文件,就能在机器上全局地定制Maven的行为,即对所有用户都生效。一般情况下,我们更偏向于复制该文件至~/.m2/目录下,然后修改该文件,在用户级别定制Maven的行为。
lib目录:该目录包含了所有Maven运行时需要的Java类库,Maven本身是分模块开发的,因此用户能看到诸如maven-core-3.0.jar、maven-model-3.0.jar之类的文件,此外这里还包含一些Maven用到的第三方依赖如commons-cli-1.2.jar、commons-lang-2.6.jar等等。
settings.xml配置文件
这里详细说一下settings.xml这个文件,这个文件用于定制Maven的行为。上面已经说到settings.xml可以放在2个位置,一个是【~/.m2/setting.xml】(默认没有,需要我们自己复制),一个是【${maven.home}/conf/setting.xml】。这2个位置的配置文件的加载顺序为【~/.m2/setting.xml】>【${maven.home}/conf/setting.xml】,为了不影响他人,所以我们将conf下的settings.xml复制到用户目录,在用户级别定制Maven的行为。
这个和系统配置环境变量有点类似,Windos和Linux都可以配置系统级别的环境变量和用户级别的环境变量,用户级别的环境变量会覆盖系统级别的环境变量。
Maven的一些常用命令
要使用Maven当然要会一些常用的命令,不然都不叫会使用Maven。
命令 | 描述 |
---|---|
mvn -version | 显示版本信息 |
mvn clean | 删除target目录 |
mvn compile | 编译src/main/java下的源代码 |
mvn package | 打包,在target下生成jar包或者war包 |
mvn test | 执行src/test/java下以Test开头或者以Test结尾的类的测试用例 |
mvn install | 打包,并把jar包或者war包复制到本地仓库,供其他模块使用 |
mvn deploy | 将打包的文件发布到私服 |
mvn dependency:tree | 打印出项目的整个依赖树 |
当然也可以将命令连着使用,比如使用【mvn clean package】清理打包;比如使用【mvn clean package -DskipTests=true】清理打包,并跳过测试用例;比如使用【mvn clean install】清理打包,并将jar包或者war包复制到本地仓库。
更多的,也可以配合将结果输出到文件来方便查看,比如【mvn dependency:tree > dependency.txt】。
pom.xml中的<dependency>标签
<dependency>标签中一般是包含<groupId>、<artifactId>和<version>三个子标签。
<groupId>表示公司域名倒过来,<artifactId>表示功能的命名,<version>表示版本号,这三个维度就确定了一个jar包,就像用(x, y, z)坐标在三维空间中确定一个唯一的点一样。
另外的,<dependency>标签中还可以包含<scope>标签,表示此依赖包的作用范围,下面列出一个<scope>参数候选值的表格。
参数 | 解释 | 是否会被打入最终的jar包 |
---|---|---|
compile | 默认的scope(不指定) | 是 |
test | 测试使用 | 否 |
provided | 编译需要 | 否 |
runtime | 编译不需要,运行时需要(接口与实现分离) | 是 |
system | 加载本地jar(很少使用) | 否 |
"长得丑的水果,都会努力让自己甜一点。"
原文地址:https://www.cnblogs.com/yanggb/p/11078256.html