Maven配置 Maven在Eclipse中的配置
Maven
Maven 概念:
Maven是基于项目对象模型(POM)，可以通过一小段描述信息来管理项目的构建、依赖管理和项目信息管理
依赖管理工具：提供中央仓库，自动下载构件。通过一组坐标，能够找到任何一个java类库。
项目信息管理工具：管理原本分散的项目信息，包括项目描述、版本控制系统地址、缺陷管理系统地址、许可证、开发者列表,
Maven 仓库:
Maven仓库就是放置所有JAR文件（WAR，ZIP，POM等等）的地方，所有Maven项目可以从同一个Maven仓库中获取自己所需要的依赖JAR
Maven安装:
1.从http://maven.apache.org/download.html下载最新的maven，解压到指定目录。
2.配置环境变量
aven在eclipse中的配置:
Maven 仓库分类:
项目的构建周期
项目开发阶段:
1创建项目
项目类型 1 javase项目2 javaee项目
2编码阶段
编码+添加依赖jar
3编译项目
jdk的javac
4运行项目（找到项目的main方法）
jdk的java命令
5打包发布
maven融合了四个阶段（控制依赖jar仓库）
SNAPSHOT（开发阶段（不稳定））
RELEASE （发布阶段（稳定））
Maven 原理:
1.jar包下载太分散导致开发人员开发周期延长 maven提供了中央仓库将所有的jar包聚在一起.
2.中央仓库 计算机网络资源有限 ,各地出现了各自的私服,降低中心服务的压力,开发者就近原则获取最近的私服,下载jar包
3.本地项目开发 如果需要下载jar包 必须依赖maven软件, maven软件需要配置私服的地址,配置本地缓存jar包位置.
阿里云私服
//maven.aliyun.com/nexus/countent/groups/public/
Maven 的项目目录:
pom.xml 用于maven的配置文件
/src 源代码目录
/src/main 工程源代码目录
/src/main/java 工程java源代码目录
/src/main/resource 工程的资源目录
/src/main/webapp web 资源文件
/src/test 单元测试目录
/src/test/java
/target 输出目录 ,将所有的输出物都存放在这个目录地下
/target/classes 编译后的class文件
Maven修改仓库地址 本地jar储存的位置:
1.修改本地仓库地址
E:\JavaWeb\mo\MAVEN\apache-maven-3.0.4_localtest\resp
2.修改访问aliyun
Maven常用命令:
1.mvn archetype:generate ：创建 Maven项目
创建项目:
2.mvn compile ：编译源代码
3.mvn test-compile ：编译测试代码
4.mvn test ： 运行应用程序中的单元测试
5.mvn site ： 生成项目相关信息的网站
6.mvn clean ：清除目标目录中的生成结果
7.mvn package ： 依据项目生成 jar文件
8.mvn install ：在本地 Repository中安装jar
9.mvn deploy：将jar包发布到远程仓库
10.mvn eclipse:eclipse ：生成 Eclipse项目文件
Maven (pom.xml):
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>cn.et</groupId><artifactId>upload-common</artifactId><version>0.0.1-SNAPSHOT</version><packaging>pom</packaging><!-- 定义所有jar包的版本库 --><properties><fileupload-version>1.3.2</fileupload-version><mysql-version>5.1.6</mysql-version></properties><!-- 子项目直接加载jar包 --><dependencies><dependency><groupId>commons-beanutils</groupId><artifactId>commons-beanutils</artifactId><version>1.9.0</version></dependency></dependencies><!-- 只是定义所有的版本信息 子项目可以选择性的加载 --><dependencyManagement><dependencies><dependency><groupId>commons-fileupload</groupId><artifactId>commons-fileupload</artifactId><version>${fileupload-version}</version></dependency><dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId><version>${mysql-version}</version></dependency></dependencies></dependencyManagement></project>tomcat插件配置端口及编码1. <build> 2. <plugins> 3. <plugin> 4. <groupId>org.codehaus.mojo</groupId> 5. <artifactId>tomcat-maven-plugin</artifactId> 6. <version>1.1</version> 7. <configuration> 8. <port>8089</port> 9. <uriEncofing>utf-8</uriEncofing> 10. </configuration> 11. </plugin> 12. </plugins> 13. </build> 介绍scope各个值得参考 1. compile：默认的scope。任何定义在compile scope下的依赖将会在所有的class paths下可用。maven工程会将其打包到最终的arifact中。如果你构建一个WAR类型的artefact，那么在compile scope下引用的JAR文件将会被集成到WAR文件内。 2. 3. provided：这个scope假定对应的依赖会由运行这个应用的JDK或者容器来提供。最好的例子就是servlet API。任何在provided scope下定义的依赖在构建时的类路径里是可用的，但是不会被打包到最终的artifact中。如果是一个WAR的文件，servlet API在构建时的类路径里是可用的，但是并不会被打包到WAR文件中。 4. 5. runtime：在runtime scope下定义的依赖只会在运行期可用，而在构建期的类路径下不可用。这些依赖将会被打包到最终的artifact中。比如你有一个基于web的应用需要在运行时访问MySQL数据库。你的代码没有任何MySQL数据库驱动的硬依赖。你的代码仅仅是基于JDBC API来编写，在构建期并不需要MySQL数据库驱动。然而，在运行期，就需要相应的驱动来操作MySQL数据库了。因此，这个驱动应该被打包到最终的artifact中。 6. 7. test：只用于测试变异的依赖（比如JUnit），execution必须定义在test scope下。这些依赖不会被打包到最终的artefact中。 8. 9. system：于provided scope很像。唯一的区别在于，在system scope中，你需要告诉Mave如何去找到这个依赖。如果你要引用的依赖在Maven仓库中不存在时，就可以用这个scope。不推荐使用system依赖。 10. 11. import：从其它的pom文件中导入依赖设置。
ゝ一纸荒年。
向右看齐
分手后的思念是犯贱
超、凢脫俗
还没有评论，来说两句吧...