build
设置
自定义打包文件
1 2 3 4
| <build> <fileName>xxx.war</fileName> </build>
|
包含特定的文件
如果一些配置文件没有放在resources/
下
有时候Mybatis
中会将编写SQL
语句的映射文件和Mapper
接口都写在src/main/java
的某个包中
此时映射文件不会被打包, 就需要单独设置
1 2 3 4 5 6 7 8 9 10 11 12
| <build> <resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> </resources> </build>
|
设置自定义插件
可以设置自定义插件, 比如修改jdk
版本, tomcat
插件, mybatis
分页插件, mybatis
逆向工程插件
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
| <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.8</source> <target>1.8</target> <encoding>UTF-8</encoding> </configuration> </plugin> <plugin> <groupId>org.apache.tomcat.maven</groupId> <artifactId>tomcat7-maven-plugin</artifactId> <version>2.2</version> <configuration> <port>8090</port> <path>/</path> <uriEncoding>UTF-8</uriEncoding> <server>tomcat7</server> </configuration> </plugin> </plugins> </builid>
|
Maven
依赖的传递特性
- 如果
Maven
项目B依赖A, C依赖B, 则项目C也依赖于项目A, 执行项目C的时候会下载AB项目的jar
包
- 简化依赖的导入过程, 确保依赖的版本正确
- 只有是
compile
范围的依赖才能够传递, 其他都不能传递, 或者如果设置了<optional>true</optinoal>
同样可以终止传递
依赖冲突
- 比如A依赖B, B依赖了X-1.0.jar, A又依赖了C, C依赖了X-2.0.jar, 此时
Maven
会自动解决冲突
- 短路优先原则(第一原则)
1 2 3
| A --> B --> C --> D --> E --> X (version 1.0) A --> F --> X (version 2.0) 此时A依赖2.0版本的X
|
- 路径长度相同, 则先声明的优先
1 2 3
| A --> E --> X (version 1.0) A --> F --> X (version 2.0) 在<dependencies>中, 先声明的路径相同会先选择
|
- 手动排除
1 2 3 4 5 6 7 8 9 10 11 12
| <dependencies> <dependency> <exclusions> <exclusion> <groupId></groupId> <artifactId></artifactId> </exclusion> <exclusions> </dependency> </dependencies>
|
继承和聚合
继承关系
Maven
项目中, 一个项目从另一个项目继承配置信息, 共享配置信息, 简化管理和维护
- 可以在父工程中同意管理项目中依赖, 对一个大型的项目进行模块拆分, 一个
project
下面, 创造很多module
, 每个module
都有自己的配置信息
- 每个
module
自己配置自己的依赖信息, 难以统一管理
- 在同一个框架中不同的
jar
包, 应该是同一个版本, 所以整个项目中使用的框架版本需要统一
- 使用框架需要的
jar
包组合, 需要反复调试, 最后确定一个可用的组合, 不用在新的项目中重新摸索
- 所以在父工程中为整个项目维护依赖信息组合保证了项目规范, 也可以沉淀技术
1 2 3 4 5 6 7 8 9 10 11 12 13
| <packaging>pom</packaging>
<pareent> <artifactId></artifactId> <groupId></groupId> <version></version> </parent>
|
聚合
- 多个项目组织到一个父项目中, 一起构建和管理, 更好管理一组相关的子项目, 简化部署过程
- 一个命令构建和发布一组相关项目
- 优化构建顺序, 避免依赖混乱构建失败的情况
- 统一管理依赖项, 避免重复定义
1 2 3 4 5 6 7 8 9 10
| <project> <groupId>com.example</groupId> <artifactId>parent-project<artifactId> <packaging>pom</packaging> <version>1.0.0</version> <modules> <module>child-project1(路径, 不是工程名)</module> <module>child-project2</module> </modules> </project>
|
私服
- 局域网内的仓库服务, 代理位于外部的远程仓库, 局域网内某个用户需要某个依赖的时候
- 请求本地仓库, 如果没有
- 请求私服, 将所需依赖下载到本地仓库, 如果私服不存在
- 请求外部远程仓库, 下载到私服, 如果外部远程仓库没有, 则直接报错
1 2
| # 第一次运行nexus时间较长 ./nexus /run
|
- 端口号默认为8081
- 如果访问网站卡住就直接命令行ctrl + c
Type
是proxy
, 则这个仓库是远程仓库的代理, 帮助从中央仓库中下载依赖, 配置Remote storage
即可
Type
是group
, 这个仓库是从远程仓库下载到本地存放的仓库(public
)
Type
是hosted
, 有两个仓库, 分别是正式版本releases
和测试版本的snapshots
- 需要修改本地的
settings.xml
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| <localRepository>D:\\new-MvnRepo</localRepository>
<mirror> <id>nexus-mine</id> <mirrorOf>central</mirrorOf> <name>Nexus mine</name> <url>http://ip:port/repository/maven-public/</url> <mirror>
<server> <id>nexus-mine</id> <username>admin</username> <password>*****</password> </server>
|
将jar
部署到Nexus
1 2 3 4 5 6 7 8
| <distributionManagement> <snapshotRepository> <id>nexus-mine</id> <name>Nexus Snapshot</name> <url>....../repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement>
|
引用别人部署的jar
1 2 3 4 5 6 7 8 9 10 11 12 13
| <repositories> <repository> <id>nexus-mine</id> <name>nexus-mine</name> <url>.../repositoryu/maven-snapshots/</url> <snapshots> <enabled>true</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </repository> </repositories>
|