1 . maven: 管理多模块开发，方便管理多模块之间的依赖
2 .依赖包的查询：
1： 所有的依赖都是通过坐标来进行存储的（GVA）
2： 有一些网上的仓库提供了坐标的查询（http://mvnrepository.com，sonatype nexus，http://search.maven.org/，http://maven.apache.org/plugins/）
3： maven首先会在本地仓库查询依赖，如果本地仓库没有就到中央仓库中查询
3. 依赖的传递性
1： 如果A依赖于B，B依赖于c，那么A久依赖于C，这就是依赖的传递性，这种依赖默认是基于compile范围进行传递的
2： compile（编译范围）
compile是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范
围。编译范围依赖在所有的classpath中可用，同时它们也会被打包。
项目对象模型
provided（已提供范围）
provided依赖只有在当JDK或者一个容器已提供该依赖之后才使用。例如，如果
你开发了一个web应用，你可能在编译classpath中需要可用的Servlet API来编
译一个servlet，但是你不会想要在打包好的WAR中包含这个Servlet API；这个
Servlet API JAR由你的应用服务器或者servlet容器提供。已提供范围的依赖在
编译classpath（不是运行时）可用。它们不是传递性的，也不会被打包。
runtime（运行时范围）
runtime依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，你
可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC驱动实
现。
test（测试范围）
test范围依赖 在一般的 编译和运行时都不需要，它们只有在测试编译和测试运
行阶段可用。测试范围依赖在之前的???中介绍过。
system（系统范围）
system范围依赖与provided类似，但是你必须显式的提供一个对于本地系统中
JAR文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库
的一部分。这样的构件应该是一直可用的，Maven也不会在仓库中去寻找它。如
果你将一个依赖范围设置成系统范围，你必须同时提供一个systemPath元素。注
意该范围是不推荐使用的（你应该一直尽量去从公共或定制的Maven仓库中引用
依赖）。
4. 模块的聚合：
<groupId>com.mavem.user</groupId>
<artifactId>user-main</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>../user-dao</module>
<module>../user-log</module>
<module>../user-core</module>
<module>../user-service</module>
</modules>
5. maven中的继承
1： 将一些公共的信息，所有模块都需要的信息放在父pom.xml文件中中
<modelVersion>4.0.0</modelVersion>
<groupId>com.maven.user</groupId>
<artifactId>user-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
2： 所有的模块中将公共的信息继承过来
<parent>
<groupId>com.maven.user</groupId>
<artifactId>user-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../user-parent/pom.xml</relativePath>
</parent>
3： 依赖的管理（排除版本冲突问题）
当你在你的超级复杂的企业中采用Maven之后，你有了两百多个相互关联的Maven项目，
你开始想知道是否有一个更好的方法来处理依赖版本。如果每一个使用如MySQL数据
库驱动依赖的项目都需要独立的列出该依赖的版本，在你需要升级到一个新版本的时
候你就会遇到问题。由于这些版本号分散在你的项目树中，你需要手工的编写每一个
引用该依赖的pom.xml，确保每个地方的版本号都更改了。即使使用了find，xargs，
和，awk，你仍然有漏掉一个POM的风险。
幸运的是，Maven在dependencyManagement元素中为你提供了一种方式来统一依赖版
本号。你经常会在一个组织或者项目的最顶层的父POM中看到dependencyManagement元
素。使用pom.xml中的dependencyManagement元素能让你在子项目中引用一个依
赖而不用显式的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥
有dependencyManagement元素的项目，然后它就会使用在这个dependencyManagement元
素中指定的版本号。 实例如下：
parent：
<modelVersion>4.0.0</modelVersion>
<groupId>com.maven.user</groupId>
<artifactId>user-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.10</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.maven.user</groupId>
<artifactId>user-dao</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.maven.user</groupId>
<artifactId>user-log</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.maven.user</groupId>
<artifactId>user-core</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.21</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.0.0.Final</version>
</dependency>
</dependencies>
</dependencyManagement>
子模块;
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
<dependency>
<groupId>com.maven.user</groupId>
<artifactId>user-dao</artifactId>
</dependency>
<dependency>
<groupId>com.maven.user</groupId>
<artifactId>user-log</artifactId>
</dependency>
</dependencies>
6. 版本的管理
总版本号.分支版本号.小版本号-里程碑版本
总版本号的变动一般表示框架的变动
分支版本号：一般表示增加了一些功能
小版本号：在分支版本上面进行bug的修复
里程碑：SNAPSHOT(开发版本)-->alpha(内部测试版本)-->beta(外部的公测版本)-->release(发布版本)-->GA(稳定版本)
user0.0.1-SNAPSHOT-->user0.0.1-Release--->user1.0.0SHAPSHOT -->user1.0.0-Rlease
-->user0.1.0-SNAPSHOT-->user0.1.0-Rlease
7. nexus私服的介绍，配置，安装
1、下载并且解压缩
2、将bin添加到环境变量
3、nexus install将nexus安装到windows的服务中
4、修改wrapper.conf文件：
# Set the JVM executable
# (modify this to absolute path if you need a Java that is not on the OS path)
wrapper.java.command=C:\Program Files\Java\jdk1.6.0_23\bin\java
2 .依赖包的查询：
1： 所有的依赖都是通过坐标来进行存储的（GVA）
2： 有一些网上的仓库提供了坐标的查询（http://mvnrepository.com，sonatype nexus，http://search.maven.org/，http://maven.apache.org/plugins/）
3： maven首先会在本地仓库查询依赖，如果本地仓库没有就到中央仓库中查询
3. 依赖的传递性
1： 如果A依赖于B，B依赖于c，那么A久依赖于C，这就是依赖的传递性，这种依赖默认是基于compile范围进行传递的
2： compile（编译范围）
compile是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范
围。编译范围依赖在所有的classpath中可用，同时它们也会被打包。
项目对象模型
provided（已提供范围）
provided依赖只有在当JDK或者一个容器已提供该依赖之后才使用。例如，如果
你开发了一个web应用，你可能在编译classpath中需要可用的Servlet API来编
译一个servlet，但是你不会想要在打包好的WAR中包含这个Servlet API；这个
Servlet API JAR由你的应用服务器或者servlet容器提供。已提供范围的依赖在
编译classpath（不是运行时）可用。它们不是传递性的，也不会被打包。
runtime（运行时范围）
runtime依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，你
可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC驱动实
现。
test（测试范围）
test范围依赖 在一般的 编译和运行时都不需要，它们只有在测试编译和测试运
行阶段可用。测试范围依赖在之前的???中介绍过。
system（系统范围）
system范围依赖与provided类似，但是你必须显式的提供一个对于本地系统中
JAR文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库
的一部分。这样的构件应该是一直可用的，Maven也不会在仓库中去寻找它。如
果你将一个依赖范围设置成系统范围，你必须同时提供一个systemPath元素。注
意该范围是不推荐使用的（你应该一直尽量去从公共或定制的Maven仓库中引用
依赖）。
4. 模块的聚合：
<groupId>com.mavem.user</groupId>
<artifactId>user-main</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>../user-dao</module>
<module>../user-log</module>
<module>../user-core</module>
<module>../user-service</module>
</modules>
5. maven中的继承
1： 将一些公共的信息，所有模块都需要的信息放在父pom.xml文件中中
<modelVersion>4.0.0</modelVersion>
<groupId>com.maven.user</groupId>
<artifactId>user-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
2： 所有的模块中将公共的信息继承过来
<parent>
<groupId>com.maven.user</groupId>
<artifactId>user-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../user-parent/pom.xml</relativePath>
</parent>
3： 依赖的管理（排除版本冲突问题）
当你在你的超级复杂的企业中采用Maven之后，你有了两百多个相互关联的Maven项目，
你开始想知道是否有一个更好的方法来处理依赖版本。如果每一个使用如MySQL数据
库驱动依赖的项目都需要独立的列出该依赖的版本，在你需要升级到一个新版本的时
候你就会遇到问题。由于这些版本号分散在你的项目树中，你需要手工的编写每一个
引用该依赖的pom.xml，确保每个地方的版本号都更改了。即使使用了find，xargs，
和，awk，你仍然有漏掉一个POM的风险。
幸运的是，Maven在dependencyManagement元素中为你提供了一种方式来统一依赖版
本号。你经常会在一个组织或者项目的最顶层的父POM中看到dependencyManagement元
素。使用pom.xml中的dependencyManagement元素能让你在子项目中引用一个依
赖而不用显式的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥
有dependencyManagement元素的项目，然后它就会使用在这个dependencyManagement元
素中指定的版本号。 实例如下：
parent：
<modelVersion>4.0.0</modelVersion>
<groupId>com.maven.user</groupId>
<artifactId>user-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.10</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.maven.user</groupId>
<artifactId>user-dao</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.maven.user</groupId>
<artifactId>user-log</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.maven.user</groupId>
<artifactId>user-core</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.21</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.0.0.Final</version>
</dependency>
</dependencies>
</dependencyManagement>
子模块;
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
<dependency>
<groupId>com.maven.user</groupId>
<artifactId>user-dao</artifactId>
</dependency>
<dependency>
<groupId>com.maven.user</groupId>
<artifactId>user-log</artifactId>
</dependency>
</dependencies>
6. 版本的管理
总版本号.分支版本号.小版本号-里程碑版本
总版本号的变动一般表示框架的变动
分支版本号：一般表示增加了一些功能
小版本号：在分支版本上面进行bug的修复
里程碑：SNAPSHOT(开发版本)-->alpha(内部测试版本)-->beta(外部的公测版本)-->release(发布版本)-->GA(稳定版本)
user0.0.1-SNAPSHOT-->user0.0.1-Release--->user1.0.0SHAPSHOT -->user1.0.0-Rlease
-->user0.1.0-SNAPSHOT-->user0.1.0-Rlease
7. nexus私服的介绍，配置，安装
1、下载并且解压缩
2、将bin添加到环境变量
3、nexus install将nexus安装到windows的服务中
4、修改wrapper.conf文件：
# Set the JVM executable
# (modify this to absolute path if you need a Java that is not on the OS path)
wrapper.java.command=C:\Program Files\Java\jdk1.6.0_23\bin\java