Maven&SVN

Maven的四⼤特性

依赖管理系统
任何基于Maven构建的项⽬⾃身也必须定义这三项属性，⽣成的包可以是Jar包，也可以是war包或者jar包。⼀个典型的依赖引⽤如下所示：、

javax.servlet com.baidu
javax.servlet-api ueditor echarts
3.1.0

坐标属性的理解
Maven坐标为各种组件引⼊了秩序，任何⼀个组件都必须明确定义⾃⼰的坐标。
groupId
定义当前Maven项⽬⾪属的实际项⽬-公司名称。（jar包所在仓库路径） 由于Maven中模块的概念，因此⼀个实际项⽬往往会被划分为很多模块。 ⽐如spring是⼀个实际项⽬，其对应的Maven模块会有很多，如spring-core,spring-webmvc等。
artifactId
该元素定义实际项⽬中的⼀个Maven模块-项⽬名， 推荐的做法是使⽤实际项⽬名称作为artifactId的前缀。 ⽐如： spring-bean, spring-webmvc等。
version
该元素定义Maven项⽬当前所处的版本。
多模块构建
项⽬复查时 dao service controller 层分离将⼀个项⽬分解为多个模块已经是很通⽤的⼀种⽅式。
在Maven中需要定义⼀个parent POM作为⼀组module的聚合POM。在该POM中可以使⽤ 标签来定义⼀组⼦模块。parent POM不会有什么实际构建产出。⽽parent POM中的build配置以及依赖配置都会⾃动继承给⼦module。
⼀致的项⽬结构
Ant时代⼤家创建Java项⽬⽬录时⽐较随意，然后通过Ant配置指定哪些属于source，那些属于
testSource等。⽽Maven在设计之初的理念就是Conversion over configuration（约定⼤于配置）。其制定了⼀套项⽬⽬录结构作为标准的Java项⽬结构,解决不同ide 带来的⽂件⽬录不⼀致问题。

Maven命令

作为开发利器的maven，为我们提供了⼗分丰富的命令，了解maven的命令⾏操作并熟练运⽤常⻅的maven命令还是⼗分必要的，即使譬如IDEA等⼯具给我提供了图形界⾯化⼯具，但其底层还是依靠maven命令来驱动的。
Maven的命令格式如下

mvn [plugin-name]:[goal-name]

命令代表的含义：执⾏ plugin-name 插件的 goal-name ⽬标
常⽤命令

注意：运⾏maven命令的时候，⾸先需要定位到maven项⽬的⽬录，也就是项⽬的pom.xml⽂件所在的⽬录。否则，必以通过参数来指定项⽬的⽬录。

命令参数
上⾯列举的只是⽐较通⽤的命令，其实很多命令都可以携带参数以执⾏更精准的任务。
-D 传⼊属性参数
-P 使⽤指定的Profile配置

Maven仓库的基本概念

对于Maven来说， 仓库只分为两类： 本地仓库和远程仓库
当Maven根据坐标寻找构件的时候，它⾸先会查看本地仓库，如果本地仓库存在，则直接使⽤； 如果本地没有，Maven就会去远程仓库查找，发现需要的构件之后，下载到本地仓库再使⽤。 如果本地仓库和远程仓库都没有，Maven就会报错。
远程仓库分为三种： 中央仓库，私服， 其他公共库。
中央仓库是默认配置下，Maven下载jar包的地⽅。
中央仓库
由于原始的本地仓库是空的，maven必须知道⾄少⼀个可⽤的远程仓库，才能执⾏maven命令的时候
下载到需要的构件。中央仓库就是这样⼀个默认的远程仓库。
私服
私服是⼀种特殊的远程仓库，它是架设在局域⽹内的仓库服务， 私服代理⼴域⽹上的远程仓库，供局域⽹内的maven⽤户使⽤。 当maven需要下载构件时， 它去私服当中找，如果私服没有， 则从外部远程仓库下载，并缓存在私服上， 再为maven提供。
公司内部应该建⽴私服：
节省⾃⼰的外⽹带宽
加速maven构建
部署第三⽅控件
提⾼稳定性
降低中央仓库的负荷
其他公共库
常⽤的阿⾥云仓库配置

<mirror> 
<id>nexus-aliyun</id> 
<mirrorOf>central</mirrorOf> 
<name>Nexus aliyun</name> 
<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>

Maven的打包操作

对于企业级项⽬，⽆论是进⾏本地测试，还是测试环境测试以及最终的项⽬上线，都会涉及项⽬的打包操作，对于每个环境下项⽬打包时，对应的项⽬所有要的配置资源就会有所区别，实现打包的⽅式有很多种，可以通过ant,获取通过idea ⾃带的打包功能实现项⽬打包，但当项⽬很⼤并且需要的外界配置很多时，此时打包的配置就会异常复杂，对于maven 项⽬，我们可以⽤过pom.xml 配置的⽅式来实现打包时的环境选择，相⽐较其他形式打包⼯具，通过maven 只需要通过简单的配置，就可以轻松完成不同环境先项⽬的整体打包。

Maven依赖的基本概念

依赖的基本配置
根元素project下的dependencies可以包含多个 dependence元素，以声明多个依赖。每个依赖都应该包含以下元素：

1. groupId, artifactId, version : 依赖的基本坐标， 对于任何⼀个依赖来说，基本坐标是最重要的，
   Maven根据坐标才能找到需要的依赖。
2. Type： 依赖的类型，⼤部分情况下不需要声明。 默认值为jar
3. Scope： 依赖范围（compile,test,provided,runtime,system）
   compile: 编译依赖范围。
   如果没有指定，就会默认使⽤该依赖范围。使⽤此依赖范围的Maven依赖，对于编译、测
   试、运⾏三种classpath都有效。
   test: 测试依赖范围。
   使⽤此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运⾏项⽬的使
   ⽤时将⽆法使⽤此类依赖。典型的例⼦就是JUnit，它只有在编译测试代码及运⾏测试的时候
   才需要。
   provided: 已提供依赖范围。
   使⽤此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运⾏时⽆效。典型的例
   ⼦是servlet-api，编译和测试项⽬的时候需要该依赖，但在运⾏项⽬的时候，由于容器已经
   提供，就不需要Maven重复地引⼊⼀遍(如：servlet-api)。
   runtime: 运⾏时依赖范围。
   使⽤此依赖范围的Maven依赖，对于测试和运⾏classpath有效，但在编译主代码时⽆效。典
   型的例⼦是JDBC驱动实现，项⽬主代码的编译只需要JDK提供的JDBC接⼝，只有在执⾏测试
   或者运⾏项⽬的时候才需要实现上述接⼝的具体JDBC驱动。
   system: 系统依赖范围。
   该依赖与三种classpath的关系，和provided依赖范围完全⼀致。但是，使⽤system范围依
   赖时必须通过systemPath元素显式地指定依赖⽂件的路径。由于此类依赖不是通过Maven仓
   库解析的，⽽且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使⽤。
4. Optional：标记依赖是否可选
5. Exclusions： ⽤来排除传递性依赖
   依赖范围
   ⾸先需要知道，Maven在编译项⽬主代码的时候需要使⽤⼀套classpath。 ⽐如：编译项⽬代码的时候需要⽤到spring-core, 该⽂件以依赖的⽅式被引⼊到classpath中。 其次， Maven在执⾏测试的时候会使⽤另外⼀套classpath。 如：junit。
   最后在实际运⾏项⽬时，⼜会使⽤⼀套classpath， spring-core需要在该classpath中，⽽junit不需要。
   那么依赖范围就是⽤来控制依赖与这三种classpath(编译classpath，测试classpath，运⾏时
   classpath)的关系， Maven有以下⼏种依赖范围：
   Compile 编译依赖范围。 如果没有指定，就会默认使⽤该依赖范围。 使⽤此依赖范围的Maven依赖， 对于编译，测试，运⾏都有效。
   Test： 测试依赖范围。 只在测试的时候需要。⽐如junit
   Provided： 已提供依赖范围。 使⽤此依赖范围的Maven依赖，对于编译和测试有效， 但在运⾏时⽆效。 典型的例⼦是servlet-API, 编译和测试项⽬的需要， 但在运⾏项⽬时， 由于容器已经提供， 就不需要Maven重复地引⼊⼀遍。
   Runtime： 运⾏时依赖范围。 使⽤此依赖范围的Maven依赖，对于测试和运⾏有效， 但在编译代码时⽆效。 典型的例⼦是：jdbc驱动程序， 项⽬主代码的编译只需要jdk提供的jdbc接⼝，只有在执⾏测试或者运⾏项⽬的时候才需要实现上述接⼝的具体jdbc驱动。
   System： 系统依赖范围。 ⼀般不使⽤。
   传递性依赖
   传递依赖机制， 让我们在使⽤某个jar的时候就不⽤去考虑它依赖了什么。也不⽤担⼼引⼊多余的依赖。 Maven会解析各个直接依赖的POM，将那些必要的间接依赖，以传递性依赖的形式引⼊到当前项⽬中。

SVN

主要作⽤

1. ⽬录版本控制
   Subversion 实现了⼀个 “虚拟” 的版本控管⽂件系统, 能够依时间跟踪整个⽬录的变动。 ⽬录和⽂件都能进⾏版本控制。
2. 真实的版本历史
   Subversion中，可以增加（add）、删除（delete）、复制（copy）和重命名（rename），⽆论是⽂件还是⽬录。所有的新加的⽂件都从⼀个新的、⼲净的版本开始。
3. ⾃动提交
   ⼀个提交动作，不是全部更新到了档案库中，就是完全不更新。这允许开发⼈员以逻辑区间建⽴并提交变动，以防⽌当部分提交成功时出现的问题。
   基本概念
   Repository（源代码库）：源代码统⼀存放的地⽅
   Checkout（提取）：当你⼿上没有源代码的时候，你需要从repository checkout⼀份
   Commit（提交）：当你已经修改了代码，你就需要Commit到repository
   Update (更新)：当你已经Checkout了⼀份源代码， Update后就可以和Repository上的源代码同步
   码，就需要这样做了）。（Commit） 4、下班时间快到了，把⾃⼰的分⽀合并到服务器主分⽀上，⼀天的⼯作完成，并反映给服务器。
   （Commit）
   注意：如果两个程序员同时修改了同⼀个⽂件， SVN可以合并这两个程序员的改动，实际上SVN管理源代码是以⾏为单位的，就是说两个程序员只要不是修改了同⼀⾏程序，SVN都会⾃动合并两种修改。如果是同⼀⾏，SVN会提示⽂件Confict, 冲突，需要⼿动确认。
   
   ⽣命周期
   创建版本库
   版本库相当于⼀个集中的空间，⽤于存放开发者所有的⼯作成果。版本库不仅能存放⽂件，还包括了每次修改的历史，即每个⽂件的变动历史。
   Create 操作是⽤来创建⼀个新的版本库。⼤多数情况下这个操作只会执⾏⼀次。当你创建⼀个新的版本库的时候，你的版本控制系统会让你提供⼀些信息来标识版本库，例如创建的位置和版本库的名字。
   检出
   Checkout 操作是⽤来从版本库创建⼀个⼯作副本。⼯作副本是开发者私⼈的⼯作空间，可以进⾏内容的修改，然后提交到版本库中。
   更新
   顾名思义，update 操作是⽤来更新版本库的。这个操作将⼯作副本与版本库进⾏同步。由于版本库是由整个团队共⽤的，当其他⼈提交了他们的改动之后，你的⼯作副本就会过期。
   让我们假设 Tom 和 Jerry 是⼀个项⽬的两个开发者。他们同时从版本库中检出了最新的版本并开始⼯作。此时，⼯作副本是与版本库完全同步的。然后，Jerry 很⾼效的完成了他的⼯作并提交了更改到版本库中。
   此时 Tom 的⼯作副本就过期了。更新操作将会从版本库中拉取 Jerry 的最新改动并将 Tom 的⼯作副本进⾏更新。
   执⾏变更
   当检出之后，你就可以做很多操作来执⾏变更。编辑是最常⽤的操作。你可以编辑已存在的⽂件来，例如进⾏⽂件的添加/删除操作。
   你可以添加⽂件/⽬录。但是这些添加的⽂件⽬录不会⽴刻成为版本库的⼀部分，⽽是被添加进待变更列表中，直到执⾏了 commit 操作后才会成为版本库的⼀部分。
   同样地你可以删除⽂件/⽬录。删除操作⽴刻将⽂件从⼯作副本中删除掉，但该⽂件的实际删除只是被添加到了待变更列表中，直到执⾏了 commit 操作后才会真正删除。
   Rename 操作可以更改⽂件/⽬录的名字。"移动"操作⽤来将⽂件/⽬录从⼀处移动到版本库中的另⼀处。
   复查变化
   当你检出⼯作副本或者更新⼯作副本后，你的⼯作副本就跟版本库完全同步了。但是当你对⼯作副本进⾏⼀些修改之后，你的⼯作副本会⽐版本库要新。在 commit 操作之前复查下你的修改是⼀个很好的习惯。
   Status 操作列出了⼯作副本中所进⾏的变动。正如我们之前提到的，你对⼯作副本的任何改动都会成为待变更列表的⼀部分。Status 操作就是⽤来查看这个待变更列表。
   Status 操作只是提供了⼀个变动列表，但并不提供变动的详细信息。你可以⽤ diff 操作来查看这些变动的详细信息。
   修复错误
   我们来假设你对⼯作副本做了许多修改，但是现在你不想要这些修改了，这时候 revert 操作将会帮助你。
   Revert 操作重置了对⼯作副本的修改。它可以重置⼀个或多个⽂件/⽬录。当然它也可以重置整个⼯作副本。在这种情况下，revert 操作将会销毁待变更列表并将⼯作副本恢复到原始状态。
   解决冲突
   合并的时候可能会发⽣冲突。Merge 操作会⾃动处理可以安全合并的东⻄。其它的会被当做冲突。例如，“hello.c” ⽂件在⼀个分⽀上被修改，在另⼀个分⽀上被删除了。这种情况就需要⼈为处理。Resolve 操作就是⽤来帮助⽤户找出冲突并告诉版本库如何处理这些冲突。
   提交更改
   Commit 操作是⽤来将更改从⼯作副本到版本库。这个操作会修改版本库的内容，其它开发者可以通过更新他们的⼯作副本来查看这些修改。
   在提交之前，你必须将⽂件/⽬录添加到待变更列表中。列表中记录了将会被提交的改动。当提交的时候，我们通常会提供⼀个注释来说明为什么会进⾏这些改动。这个注释也会成为版本库历史记录的⼀部分。Commit 是⼀个原⼦操作，也就是说要么完全提交成功，要么失败回滚。⽤户不会看到成功提交⼀半的情况。