代码拉取完成，页面将自动刷新
同步操作将从 Java精选/Ebooks 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
1、maven&ant同属apach是流行的构建工具
都是为了简化软件开发而存在的。但是maven因为自身管理一个项目对象模型（project object model），这个模型其实就是抽象了一个项目的开发流程，它包含了一个项目的生命周期的各个阶段，并将这个周期固定下来，这也就是约定大于配置。约定大于配置的意思就是，我maven将项目开发的各个阶段固定起来了，每个文件的存放位置，每个阶段要生成什么文件、保存为什么格式并且要把它放在什么位置，我都固定好了。我知道一个软件是怎么开发出来，如果一个项目要使用maven，可以，但你要遵循我的规则，文件目录不要乱建乱放，只有这样maven才会将源码用起来。这就是约定大于配置，因为maven已经将流程固定下来了，只要遵守约定，就不需要自己手动去配置了，这将大大地提高开发效率。
2、maven的中央仓库和pom.xml文件
中央仓库统一存放了开发用到的各种jar包，要用时只需要添加依赖到pom文件中，maven就会自动下载，当然为了方便一般会在本地建一个仓库，减少下载时间。pom文件是maven的配置文件，maven就是通过管理pom文件和一些核心插件来管理项目。当然我前面将maven拟人化了，其实maven是没有智力的，一切都是封装好的流程，只是maven将很多操作隐藏起来了。
3、ant的build.xml文件
build文件是ant的配置文件，ant依靠它来执行操作，与maven不同的是ant没有固定一条程序链。你想要执行什么操作以及操作之间的顺序和依赖关系，都需要手动添加到build文件中，一点一滴都要写清楚，否则ant就不会执行。
4、maven和ant区别
Maven拥有约定，只要遵守约定，它就知道你的源代码在哪里。Maven是声明式的。你需要做的只是创建一个pom.xml文件然后将源代码放到默认的目录。Maven会帮你处理其它的事情。Maven有一个生命周期，当你运行mvn install的时候被调用。这条命令告诉Maven执行一系列的有序的步骤，直到到达你指定的生命周期。缺点是运行许多默认目标。
而ant没有约定，项目生命周期，它是命令式的。所有操作都要手动去创建、布置。甚至连build.xml文件都需要手动创建。
1）Maven是一个优秀的项目构建工具。
使用Maven可以比较方便的对项目进行分模块构建，这样在开发或测试打包部署时，会大大的提高效率。
2）Maven可以进行依赖的管理。
使用Maven 可以将不同系统的依赖进行统一管理，并且可以进行依赖之间的传递和继承。
Maven可以解决jar包的依赖问题，根据JAR包的坐标去自动依赖/下载相关jar，通过仓库统一管理jar包。
多个项目JAR包冗余，使用Maven解决一致性问题。
4）屏蔽开发工具之间的差异，例如：IDE，Eclipse，maven项目可以无损导入其他编辑器。
第一步，查找Maven加载的时候是什么版本的jar包，通过使用“mvn dependency:tree”命令查看依赖树，或者使用IDEA Maven Helper插件。
第二步，通过Maven的依赖原则来调整坐标在pom文件的申明顺序或者使用将冲突中不想要的jar引入的jar进行<exclusions>去除掉。
项目中引入另一个maven项目依赖，通过依赖传递，会将jar包传递进来，如果不需要某个jar包就可以使用如下配置：
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
<exclusions>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
POM工程
POM工程是逻辑工程。用在父级工程或聚合工程中。用来做jar包的版本控制。
JAR工程
将系统打包成jar工程，用作jar包使用。是最常见的本地工程Java Project。
WAR工程
将系统打包成war工程，发布在服务器上的工程。比如网站或服务。
常见的网络工程Dynamic Web Project。
war工程默认没有WEB-INF目录及web.xml配置文件，但是在IDE工具中通常会显示工程错误，需要提供完整工程结构才可以解决问题。
Maven构建生命周期经历了一组阶段，这些阶段称为构建阶段。 例如，默认生命周期由以下阶段组成。
validate 验证
compile 编译
test 测试
package 包
verify 校验
install 安装
deploy 部署
LASTEST：是指某个特定构件最新的发布版或者快照版（SNAPSHOT），最近被部署到某个特定仓库的构件。
RELEASE：是指仓库中最后的一个非快照版本，代表稳定的版本。
SNAPSHOT：泛指。版本一般用于开发过程中，代表不稳定、尚处于开发中的版本。
dependencyManagement用来统一管理依赖版本的，其目的是防止不同子项目引用不同的版本而导致编写代码的时候出现意外错误。之前的面试题已经说明了该参数的作用，此处就不在阐述。
配置方式
1、假设父工程pom文件，如下：
<groupId>com.jingxuan</groupId>
<artifactId>J</artifactId> //项目名称J
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
//对项目A的版本进行了统一管理，子类使用A时可以不写<version>标签。
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.jingxuan</groupId>
<artifactId>A</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
</dependencyManagement>
2、假设子工程需要使用A包
方式一：parent标签，子类POM文件编写如下：
//引用父工程J
<parent>
<groupId>com</groupId>
<artifactId>P</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
//子工程使用A包
<dependencies>
<dependency>
<groupId>com.jingxuan</groupId>
<artifactId>A</artifactId>
</dependency>
</dependencies>
方式二：import标签，子类POM文件编写如下：
//子工程使用A包，注意使用import标签时，不再使用<parent>标签
<dependencies>
<dependency>
<groupId>com.wentian</groupId>
<artifactId>A</artifactId>
//这里并没有使用<version>标签
</dependency>
</dependencies>
//表示将项目J的dependencyManagement拿到本POM中，不再继承parent
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com</groupId>
<artifactId>P</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>pom</type> //必须是type=pom
<scope>import</scope> //必须是scope=import
</dependency>
</dependencies>
</dependencyManagement>
提交项目文件命令
git commit -a
含义：-a参数是指通过在命令行上加-a指示git提交已修改的所有被跟踪文件的新内容。
注意的是如果第一次提交新文件，可以在执行git commit -a命令之前先执行git add 命令。
dependencies即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项（全部继承）。
dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;另外如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。
dependencies中的jar直接加到项目中，管理的是依赖关系（如果有父pom和子pom，则子pom中只能被动接受父类的版本）；
dependencyManagement主要管理版本，对于子类继承同一个父类是很有用的，集中管理依赖版本不添加依赖关系，对于其中定义的版本，子pom不一定要继承父pom所定义的版本。
开发过程中经常碰到一些冲突问题，比如同时修改公共类的公共方法，一人提交后，另外一人再提交就会报冲突的错误。
发生冲突，在IDE里面一般都是对比本地文件和远程分支的文件，然后把远程分支上文件的内容手工修改到本地文件，然后再提交冲突的文件使其保证与远程分支的文件一致，这样才会消除冲突，然后再提交其修改的部分。
注意的是修改本地冲突文件与远程仓库的文件保持一致后，需要提交后才能消除冲突，否则无法继续提交。必要时可与其他提交人员交流沟通，消除冲突。
发生冲突，也可以使用命令。
1）使用git stash命令，把工作区的修改提交到栈区，目的是保存工作区的修改；
2）使用git pull命令，拉取远程分支上的代码并合并到本地分支，目的是消除冲突；
3）使用git stash pop命令，把保存在栈区的修改部分合并到最新的工作空间中。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
