Apache Maven是一个软件项目管理和理解工具。基于项目对象模型(POM)的概念,Maven可以从一个中心信息管理项目的构建,报告和文档。
官网
在maven的安装目录找到settings.xml文件,在里面添加如下代码
<profile>
<id>jdk-1.8id>
<activation>
<activeByDefault>trueactiveByDefault>
<jdk>1.8jdk>
activation>
<properties>
<maven.compiler.source>1.8maven.compiler.source>
<maven.compiler.target>1.8maven.compiler.target>
<maven.compiler.compilerVersion>1.8maven.compiler.compilerVersion>
properties>
profile>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.pluginsgroupId>
<artifactId>maven-compiler-pluginartifactId>
<version>3.7version>
<configuration>
<source>1.8source>
<target>1.8target>
configuration>
plugin>
plugins>
build>
<properties>
<project.build.sourceEncoding>UTF-8project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8project.reporting.outputEncoding>
properties>
应用程序源位于$ {basedir} / src / main / java中,
测试源位于$ {basedir} / src / test / java中,
其中$ {basedir}表示包含pom的目录.xml
编译后的类被放在$ {basedir} / target / classes中
请注意,下面显示的pom.xml文件中的version标记的值具有后缀:-SNAPSHOT
<groupId> ... groupId>
<artifactId> my-app artifactId>
...
<version> 1.0-SNAPSHOT version>
<name> Maven Quick Start Archetype name>
...
该快照值指的是沿着一个发展分支的“最新”的代码,并且不保证该代码是稳定的或不变。相反,“发布”版本中的代码(没有后缀SNAPSHOT的任何版本值)是不变的。
快照(SNAPSHOT)是一种特殊的版本,指定了某个当前的开发进度的副本。不同于常规的版本,Maven每次构建都会在远程仓库中检查新的快照。
现在data-service团队会每次发布更新代码的快照到仓库中,比如说data-service:1.0-SNAPSHOT来替代旧的快照jar包。
注意:每次更新jar包时,版本好不变,且后缀必须带上-SNAPSHOT。
版本(Version)的情况下,如果Maven以前下载过指定的版本文件,比如说data-service:1.0,Maven将不会再从仓库下载新的可用的1.0文件。若要下载更新的代码,data-service的版本需要升到1.1。
快照(Snapshot)的情况下,每次app-ui团队构建他们的项目时,Maven将自动获取最新的快照(data-service:1.0-SNAPSHOT)。
备注:版本(Version)存放在Release发布仓库。快照(Snapshot)存放在Snapshot快照仓库。
注意:版本(Version)的概念,只要不带有-SNAPSHOT的关键字时,都会认为这是一个在Release发布仓库的jar包。其中在Release发布仓库的jar包命名除了具体的版本号之后还可以带上比如:1.0-Release、1.0-rc1等等的字样。
Maven中的仓库分为两种,Snapshot快照仓库和Release发布仓库。Snapshot快照仓库用于保存开发过程中的不稳定版本,Release正式仓库则是用来保存稳定的发行版本。定义一个组件/模块为快照版本,只需要在pom.xml文件中在该模块的版本号后加上-SNAPSHOT即可(注意这里必须是大写),如下所示:
<groupId>com.jsoft.testgroupId>
<artifactId>testcommonartifactId>
<version>0.1-SNAPSHOTversion>
<packaging>jarpackaging>
Maven会根据模块的版本号(pom.xml文件中的version)中是否带有-SNAPSHOT来判断是快照版本还是正式版本。如果是快照版本,那么在mvn deploy时会自动发布到快照版本库中,而使用快照版本的模块,在不更改版本号的情况下,直接编译打包时,Maven会自动从镜像服务器上下载最新的快照版本。如果是正式发布版本,那么在mvn deploy时会自动发布到正式版本库中,而使用正式版本的模块,在不更改版本号的情况下,编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。
所以,我们在开发阶段,可以将公用库的版本设置为快照版本,而被依赖组件则引用快照版本进行开发,在公用库的快照版本更新后,我们也不需要修改pom.xml文件提示版本号来下载新的版本,直接Maven执行相关编译、打包命令即可重新下载最新的快照库了,从而也方便了我们进行开发。
虽然,快照的情况下,Maven在日常工作中会自动获取最新的快照,你也可以在任何Maven命令中使用-U参数强制Maven下载最新的快照构建。命令如下:
mvn clean package -U
Project Aggregation类似于Project Inheritance。但是,它不是从模块中指定父POM,而是从父POM指定模块。通过这样做,父项目现在知道它的模块,并且如果针对父项目调用Maven命令,那么Maven命令也将被执行到父模块。要执行Project Aggregation,您必须执行以下操作:
将父POM包装更改为值“pom”。
在父POM中指定其模块的目录(子POM)
project.basedir | 当前项目所在的目录。 |
---|---|
project.baseUri | 当前项目所在的目录,表示为URI。自Maven 2.1.0起 |
maven.build.timestamp | 表示构建开始的时间戳。自Maven 2.1.0-M1起 |
scope的默认值是compile
compile
默认就是compile,什么都不配置也就是意味着compile。compile表示被依赖项目需要参与当前项目的编译,当然后续的测试,运行周期也参与其中,是一个比较强的依赖。打包的时候通常需要包含进去。
test
scope为test表示依赖项目仅仅参与测试相关的工作,包括测试代码的编译,执行。比较典型的如junit。
runntime
runntime表示被依赖项目无需参与项目的编译,不过后期的测试和运行周期需要其参与。与compile相比,跳过编译而已,说实话在终端的项目(非开源,企业内部系统)中,和compile区别不是很大。比较常见的如JSR×××的实现,对应的API jar是compile的,具体实现是runtime的,compile只需要知道接口就足够了。oracle jdbc驱动架包就是一个很好的例子,一般scope为runntime。另外runntime的依赖通常和optional搭配使用,optional为true。我可以用A实现,也可以用B实现。
provided
provided意味着打包的时候可以不用包进去,别的设施(Web Container)会提供。事实上该依赖理论上可以参与编译,测试,运行等周期。相当于compile,但是在打包阶段做了exclude的动作。
system
从参与度来说,也provided相同,不过被依赖项不会从maven仓库抓,而是从本地文件系统拿,一定需要配合systemPath属性使用。
当我们的项目模块很多的时候,我们使用Maven管理项目非常方便,帮助我们管理构建、文档、报告、依赖、scms、发布、分发的方法。可以方便的编译代码、进行依赖管理、管理二进制库等等。
在我们项目顶层的POM文件中,我们会看到dependencyManagement元素。通过它元素来管理jar包的版本,让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走,直到找到一个拥有dependencyManagement元素的项目,然后它就会使用在这个dependencyManagement元素中指定的版本号
相对于dependencyManagement,所有生命在dependencies里的依赖都会自动引入,并默认被所有的子项目继承。
dependencies即使在子项目中不写该依赖项,那么子项目仍然会从父项目中继承该依赖项(全部继承)
dependencyManagement里只是声明依赖,并不实现引入,因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖,是不会从父项目中继承下来的;只有在子项目中写了该依赖项,并且没有指定具体版本,才会从父项目中继承该项,并且version和scope都读取自父pom;另外如果子项目中指定了版本号,那么会使用子项目中指定的jar版本。
src ——> 源代码和测试代码的根目录
main ——> 应用代码的源目录
Java ——> 源代码
resources ——> 项目的资源文件
test ——> 测试代码的源目录
java ——> 测试代码
resources ——> 测试的资源文件
target ——> 编译后的类文件、jar文件等