推荐阅读(点击便可跳转阅读)java
1. SpringBoot内容聚合mysql
2. 面试题内容聚合web
3. 设计模式内容聚合面试
4. Mybatis内容聚合spring
5. 多线程内容聚合sql
maven是Apache下的一个纯java开发的一个开源项目,它是一款可以抽象构建过程,而且提供依赖管理,中央仓库,自动下载构建等功能的项目构建工具。mongodb
假如咱们在开发两个Java项目,暂时称之为A,B,这两个项目中对于一些特殊功能会有互相依赖的状况下,该如何作二者之间较好的关联呢?是打算在A,B两边共用一套代码进行关联吗?( 这样的作法会很是难以进行后期的维护 )数据库
若是咱们将共用的代码打包成jar引入项目中使用的话,那么后期进行代码更新的话是否又要对全部引入的jar进行更新呢?这样的作法彷佛很是繁琐。json
回想起之前作开发的时候,因为maven技术尚未出现,使用ssh框架进行开发的时候,全部的jar都须要人为的进行统一导入和维护,致使后期的维护难度极高。设计模式
在maven这款工具里面,有一个特别的概念叫作坐标。这个坐标可不是咱们数学里面说的那个坐标,可是在设定上确实和数学的坐标有一点相似,就是每一个坐标都会拥有属于它本身的惟一标识。在maven里面也不例外:
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.47</version>
</dependency>复制代码
例如上边的这段坐标信息,groupId 一般会用于标识该jar所属的实际项目,因为一般一个项目可能会划分为了多个模块,所以artifactId 则是对于该项目的某个模块进行了一个明确的标识。version元素更多的是定义了该构件的真实版本。一般咱们会称呼这一段 dependency 为依赖。
对于依赖的读取还有一个叫作scope的配置
scope的分类 | 讲解 |
---|---|
compile | 默认状况下就是compile类型, 意味着该依赖既要参与编译又要参与后期的测试等环节 |
test | 表示该依赖仅仅参加和测试有关的工做 |
provided | 能够参与编译,测试,运行等周期, 可是在打包的时候会进行exclude的相应操做, 其余方面和compile差别不大 |
runntime | 在编译环节不会参与进来,我的感受和compile差别不大 |
system | 一般是指不从仓库读取依赖,而是经过本地路径来读取依赖, 所以常与systemPath标签结合使用 |
固然若是对于每一个依赖咱们都进行相应单独的version设置,那么管理起来会有些繁琐,所以可使用或者标签进行统一的管理,例以下方的这两组案例:
基于parent的依赖管理:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.4.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>复制代码
基于properties的依赖管理,在properties里面咱们能够进行整个项目的统一字符集编码管理或者对于一些依赖jar包统一版本号的管理:
<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>复制代码
那么当咱们将相应的依赖导入到了工程里面以后,又会发生什么事情了呢?
maven的内部会有一个从网上边下载依赖的功能,咱们一般称这个拥有依赖jar的平台为仓库。
在maven里面仓库有分为多种:本地仓库,第三方仓库,中央仓库
一般被下载下来的jar会存在开发者电脑上的本地仓库,这个默认的地址是在 $user.home/.m2/repository目录底下:
这里面存储了许多本身曾经下载过的jar,这样就能够避免往后再次使用到相同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
在idea编译器里面,对于maven工程的建立时候,默认的结构一般都是以下所示:
在开发的时候,一般代码编写都是在main文件夹底下进行,而若是须要编写相应的测试代码则在test目录底下进行,java目录下通常是放置咱们的代码内容,resources目录底下更多的是存放一些咱们的配置文件,例如说xml,yml,properties这类型的文件内容。
固然若是是建立maven-web结构的工程的话,能够在创建maven工程的时候选择相应的构建模板:
项目结构以下所示:(可能idea版本不一样,最终的成效截图会有所出入)
固然,如今的项目大多都是基于父子工程的偏多,maven里面也支持这种工程的搭建,一般咱们能够事先构建好一个父工程结构,而后再在父工程的基础上边构建相应的module工程。例以下边的工程截图:
其实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
在实际的项目开发过程当中,咱们一般会须要结合实际的应用场合切换不一样的运行环境(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>复制代码
在pom文件里面配置以上相应的profile内容以后,在进行工程打包的时候默认经过mvn clean package -Pdev(对应profile文件的id)的方式来判断不一样环境下的读取方式。
这样咱们就能够更加专心的进行代码开发工做,基于这种思路,咱们能够经过编写相应的脚原本实现不一样环境下自动化打包的功能。