Maven项目对象模型(POM),可以通过一小段描述信息来管理项目的构建,报告和文档的软件项目管理工具。
Maven 除了以程序构建能力为特色之外,还提供高级项目管理工具。由于 Maven 的缺省构建规则有较高的可重用性,所以常常用两三行 Maven 构建脚本就可以构建简单的项目。由于 Maven 的面向项目的方法,许多 Apache Jakarta 项目发文时使用 Maven,而且公司项目采用 Maven 的比例在持续增长。
Maven这个单词来自于意第绪语(犹太语),意为知识的积累,最初在Jakata Turbine项目中用来简化构建过程。当时有一些项目(有各自Ant build文件),仅有细微的差别,而JAR文件都由CVS来维护。于是希望有一种标准化的方式构建项目,一个清晰的方式定义项目的组成,一个容易的方式发布项目的信息,以及一种简单的方式在多个项目中共享JARs。
前面对maven已经有了一个大致的了解了,接下来要使用,如何在机器上安装maven呢,这里我们以windows系统为例来讲解安装步骤,其他系统的安装,百度一下。
1准备:首先,我们需要下载 maven 软件(http://maven.apache.org/download.cgi)
接下来,准备安装,maven 是一个免安装版的软件,所谓的免安装版,是指无需向安装 “腾讯QQ”那样根据安装向导,一步一步的点击。我们只需要把 maven的压缩包文件解压到指定的位置即可。为了避免误删除,请不要把它直接解压到桌面,良好的软件管理和归档也是一项技能。另外,maven 软件依赖于 java运行环境,所以先要检查机器上是否已经安装了Java环境,这里一定要注意,需要配置JAVA_HOME 环境变量,maven启动时会去查找这个环境变量,若果没有则无法启动。
2安装:解压安装包到指定位置
目录解释:
bin: 存放mavn 运行的脚本命令。Windows系统下使用*.bat boot:启动mavn的工具,和maven 自身提供的类加载器 conf:存放maven配置文件,如settingx.xml lib:存放 maven 运行时需要的 Java类库。
3安装:配置环境变量
1、新建JAVA_HOME 环境变量(如果之前配置过,跳过这一步)
2、新建 M2_HOME 环境变量
3、编辑 path 环境变量
4测试:
1认识Pom文件
Pom(Project Object Model) 项目工程对象模型,是Maven的核心概念,Pom是一个xml文件,Maven工具就是依靠此文件来,构建工程的。以下是一个简单的 pom 文件的示例
4.0.0
com.xingxue
maven-demo
1.0-SNAPSHOT
jar
FristApp
http://maven.apache.org
junit
junit
4.12
test
Maven 坐标:描述一个软件的位置信息的手段
com.xingxue maven-demo 1.0-SNAPSHOT
理解:
2编写代码
maven 工程目录规范:
标准目录结构:
src/main/java | application library sources - java源代码文件 |
---|---|
src/main/resources | application library resources - 资源库,会自动复制到classes文件夹下 |
src/main/filters | resources filter files - 资源过滤文件 |
src/main/assembly | assembly descriptor - 组件的描述配置,如何打包 |
src/main/config | configuration files - 配置文件 |
src/main/webapp | web application sources - web应用的目录,WEB-INF,js,css等 |
src/main/bin | 脚本库 |
src/test/java | 单元测试java源代码文件 |
src/test/resources | 测试需要的资源库 |
src/test/filters | 测试资源过滤库 |
src/site | 一些文档 |
target/ | 存放项目构建后的文件和目录,jar包,war包,编译的class文件等;Maven构建时生成的 |
pom.xml | 工程描述文件 |
LICENSE.txt | license |
README.txt | read me |
package com.xingxue.domain;
public class Student{
private String name;
private int age;
public Student(String name,int age){
this.name=name;
this.age=age;
}
public void sayHello(){
System.out.println("大家好!我是"+name+"今年"+age+"岁了");
}
}
import org.junit.Test;
import com.xingxue.domain.Student;
public class AppTest{
@Test
public void test(){
Student st = new Student("aaa",10);
st.sayHello();
}
}
3测试 > mvn test
Maven常用命令
mvn --version(mvn -v):显示版本号,Maven home,Java 版本,java home,操作系统,编码等
mvn compile :编译源代码
mvn test-compile :编译测试代码
mvn test : 运行应用程序中的单元测试
mvn site : 生成项目相关信息的网站
mvn clean :清除目标目录中的生成结果
mvn package : 依据项目生成 jar 文件
mvn package -Dmaven.test.skip=ture 打包时跳过测试
生成包名称为:
mvn install :在本地 Repository 中安装 jar
手动创建项目比较麻烦,各种创建文件,可以使用一个项目模板来创建一个项目(这个模板就是骨架)在maven 中使用 mvn archetype:generate 命令根据提示向导创建项目
7 是一个 maven官方提供的 java普通工程的骨架
10 是一个 maven官方提供的 javaweb 工程的骨架
Maven有以下三种标准的生命周期:
clean
default(或 build)
site
1、clean生命周期:
pre-clean
clean
post-clean
2、默认生命周期:
生命周期阶段 描述 validate 验证项目是否正确,并且所有必要的信息可用于完成构建过程 initialize 建立初始化状态,例如设置属性 generate-sources 产生任何的源代码包含在编译阶段 process-sources 处理源代码,例如,过滤器值 generate-resources 包含在包中产生的资源 process-resources 复制和处理资源到目标目录,准备打包阶段 compile 编译该项目的源代码 process-classes 从编译生成的文件提交处理,例如:Java类的字节码增强/优化 generate-test-sources 生成任何测试的源代码包含在编译阶段 process-test-sources 处理测试源代码,例如,过滤器任何值 test-compile 编译测试源代码到测试目标目录 process-test-classes 处理测试代码文件编译生成的文件 test 运行测试使用合适的单元测试框架(JUnit) prepare-package 执行必要的任何操作的实际打包之前准备一个包 package 提取编译后的代码,并在其分发格式打包,如JAR,WAR或EAR文件 pre-integration-test 完成执行集成测试之前所需操作。例如,设置所需的环境 integration-test 处理并在必要时部署软件包到集成测试可以运行的环境 pre-integration-test 完成集成测试已全部执行后所需操作。例如,清理环境 verify 运行任何检查,验证包是有效的,符合质量审核规定 install 将包安装到本地存储库,它可以用作当地其他项目的依赖 deploy 复制最终的包到远程仓库与其他开发者和项目共享
3、site生命周期
pre-site
site
post-site
site-deploy
从命令行执行Maven任务的最主要的方式就是调用Maven的生命周期阶段,需要注意的是,各个生命周期阶段是相互独立的,而一个生命周期的阶段是有前后依赖关系的。比如 mvn clean 该命令调用了clean生命周期的 的clean阶段 但是实际执行的只有 pre-clean 和 clean 阶段。
maven仓库就是存放jar包的地方
1、为什么需要仓库?
2、仓库在哪里?
仓库类型 * 根据仓库位置的不同,仓库的类型也不相同
本地仓库 -- 在自己电脑上的仓库
远程仓库(私服) -- 在局域网内的仓库
中央仓库 -- 网络上的仓库(是由apache团队下的maven团队维护的仓库,包括了全球基本上所有的jar包)
配置本地仓库:打开setitng.xml
F:\repo
如果不配置,则通常默认为 C:\Users\Administrator.m2\repository 在c盘中。
配置中央仓库:
nexus-aliyun
*
Nexus aliyun
http://maven.aliyun.com/nexus/content/groups/public
中央仓库为境外网站,速度比较慢,国内多用阿里的镜像速度还可以
注意:当在项目中声明依赖时,maven会先到本地仓库中去查找,本地仓库没有,才会去中央仓库下载。
junit
junit
4.12
test
Maven 除了构建项目的作用以外的另一个强大功能就是管理依赖,回想没有maven工具时,开发一个项目,我们需要去各个网站上去下载各种jar包,然后拷到项目中
使用maven再也不需要东拼西凑下载jar包了,开发者只需要在pom文件中声明需要的依赖,maven 自动到maven仓库中去下载,同时,还能分析依赖关系。
依赖范围
Scope | 描述 | |
---|---|---|
compile | 这个范围表明依赖可用项目的类路径中。这是默认的范围。 | spring-xx |
provided | 这表明依赖范围提供的JDK或服务器/容器在运行时。 | servlet-api |
runtime | 这个范围表明,依赖不需要编译,但在执行期间是必需的。 | mysql-connector-5.1.jar |
test | 这个范围表明,依赖只是用于测试编译和执行阶段。 | junit |
system | 这表明你必须提供范围系统路径。 | |
import | 这个范围时才使用的类型是pom的依赖。 这个范围表明,POM应该替换为指定依赖项POM的< dependencyManagement >部分。 |
Maven官方 依赖查询网站:http://mvnrepository.com/
依赖传递
当项目中引入hibernate-core 时,该依赖又依赖于 slf4j-api ,这时slf4j就是hibernate-core 的传递依赖。传递依赖的作用域是通过 第一和 第二直接依赖决定的如下表格:
第一直接依赖\第二直接依赖 | compile | test | provided | runtime |
---|---|---|---|---|
compile | compile | - | - | runtime |
test | test | - | - | test |
provided | provided | - | provided | provided |
runtime | runtime | - | - | runtime |
规律:
当第二依赖为 compile 传递依赖 和第一直接依赖范围一致。 当第二依赖为 test 依赖不传递。 当第二依赖为 provided 只有 当第一直接依赖为也为provided时发生,且为provided。 当第二依赖为 runtime (除compile)传递依赖于第一依赖相同。
依赖原则
Maven引入的传递依赖机制,一方面大大简化和方便了依赖声明,另一方面,大部分情况下我们只需要关心项目的直接依赖是什么,而不用考虑这些直接依赖会引入什么传递性依赖。但有时候,当传递依赖出现问题的时候,我们就需要清楚的知道该传递性依赖是从那条路径引入的。
例如,项目A有 如下依赖关系: A- > B -> C -> X(1.0) , A -> D -> X(2.0) maven 用哪个?
项目B有 如下依赖关系: A- > B -> Y(1.0) , A -> C -> Y(2.0) maven用哪个?
这时候就需要了解Maven的依赖原则
第一原则:路径最近优先
第二原则:第一声明优先
Eclipse 集成 Maven (百度)
Idea 集成 Maven(百度)
一、概述
我们都知道Maven本质上是一个插件框架,它的核心并不执行任何具体的构建任务,所有这些任务都交给插件来完成。
例如编译源代码是由maven-compiler-plugin完成的。
进一步说,每个任务对应了一个插件目标(goal),每个插件会有一个或者多个目标。
例如maven-compiler-plugin的compile目标用来编译位于src/main/java/
目录下的主源码,testCompile目标用来编译位于src/test/java/
目录下的测试源码。
二、执行
用户可以通过两种方式调用Maven插件目标。
第一种方式是将插件目标与生命周期阶段(lifecycle phase)绑定,这样用户在命令行只是输入生命周期阶段而已。
例如Maven默认将maven-compiler-plugin的compile目标与compile生命周期阶段绑定,因此命令mvn compile实际上是先定位到compile这一生命周期阶段,然后再根据绑定关系调用maven-compiler-plugin的compile目标。
第二种方式是直接在命令行指定要执行的插件目标。
例如mvn archetype:generate 就表示调用maven-archetype-plugin的generate目标,这种带冒号的调用方式与生命周期无关。
三、插件库
认识上述Maven插件的基本概念能帮助你理解Maven的工作机制,不过要想更高效率地使用Maven,了解一些常用的插件还是很有必要的,这可以帮助你避免一不小心重新发明轮子。
多年来Maven社区积累了大量的经验,并随之形成了一个成熟的插件生态圈。
Maven官方有两个插件列表:
第一个列表的GroupId为org.apache.maven.plugins,这里的插件最为成熟,具体地址为:http://maven.apache.org/plugins/index.html。
第二个列表的GroupId为org.codehaus.mojo,这里的插件没有那么核心,但也有不少十分有用,其地址为:http://mojo.codehaus.org/plugins.html。
四、插件介绍
maven-antrun-plugin
http://maven.apache.org/plugins/maven-antrun-plugin/
maven-antrun-plugin能让用户在Maven项目中运行Ant任务。用户可以直接在该插件的配置以Ant的方式编写Target,然后交给该插件的run目标去执行。
在一些由Ant往Maven迁移的项目中,该插件尤其有用。
此外当你发现需要编写一些自定义程度很高的任务,同时又觉得Maven不够灵活时,也可以以Ant的方式实现之。maven-antrun-plugin的run目标通常与生命周期绑定运行。
http://maven.apache.org/archetype/maven-archetype-plugin/
Archtype指项目的骨架,Maven初学者最开始执行的Maven命令可能就是mvn archetype:generate,这实际上就是让maven-archetype-plugin生成一个很简单的项目骨架,帮助开发者快速上手。
可能也有人看到一些文档写了mvn archetype:create,但实际上create目标已经被弃用了,取而代之的是generate目标,该目标使用交互式的方式提示用户输入必要的信息以创建项目,体验更好。
maven-archetype-plugin还有一些其他目标帮助用户自己定义项目原型,例如你由一个产品需要交付给很多客户进行二次开发,你就可以为他们提供一个Archtype,帮助他们快速上手。
http://maven.apache.org/plugins/maven-assembly-plugin/
maven-assembly-plugin的用途是制作项目分发包,该分发包可能包含了项目的可执行文件、源代码、readme、平台脚本等等。
maven-assembly-plugin支持各种主流的格式如zip、tar.gz、jar和war等,具体打包哪些文件是高度可控的。
例如用户可以按文件级别的粒度、文件集级别的粒度、模块级别的粒度、以及依赖级别的粒度控制打包,此外,包含和排除配置也是支持的。
maven-assembly-plugin要求用户使用一个名为assembly.xml
的元数据文件来表述打包,它的single目标可以直接在命令行调用,也可以被绑定至生命周期。
http://maven.apache.org/plugins/maven-dependency-plugin/
maven-dependency-plugin最大的用途是帮助分析项目依赖
dependency:list能够列出项目最终解析到的依赖列表
dependency:tree能进一步的描绘项目依赖树
dependency:analyze可以告诉你项目依赖潜在的问题
如果你有直接使用到的却未声明的依赖,该目标就会发出警告。
maven-dependency-plugin还有很多目标帮助你操作依赖文件,例如dependency:copy-dependencies能将项目依赖从本地Maven仓库复制到某个特定的文件夹下面。
http://maven.apache.org/plugins/maven-enforcer-plugin/
在一个稍大一点的组织或团队中,你无法保证所有成员都熟悉Maven,那他们做一些比较愚蠢的事情就会变得很正常。
例如给项目引入了外部的SNAPSHOT依赖而导致构建不稳定,使用了一个与大家不一致的Maven版本而经常抱怨构建出现诡异问题。
maven-enforcer-plugin能够帮助你避免之类问题,它允许你创建一系列规则强制大家遵守,包括设定Java版本、设定Maven版本、禁止某些依赖、禁止SNAPSHOT依赖。
只要在一个父POM配置规则,然后让大家继承,当规则遭到破坏的时候,Maven就会报错。
除了标准的规则之外,你还可以扩展该插件,编写自己的规则。maven-enforcer-plugin的enforce目标负责检查规则,它默认绑定到生命周期的validate阶段。
http://maven.apache.org/plugins/maven-help-plugin/
maven-help-plugin是一个小巧的辅助工具。
最简单的help:system可以打印所有可用的环境变量和Java系统属性。
help:effective-pom和help:effective-settings最为有用,它们分别打印项目的有效POM和有效settings,有效POM是指合并了所有父POM(包括Super POM)后的XML,
当你不确定POM的某些信息从何而来时,就可以查看有效POM。
有效settings同理,特别是当你发现自己配置的settings.xml没有生效时,就可以用help:effective-settings来验证。
此外,maven-help-plugin的describe目标可以帮助你描述任何一个Maven插件的信息,还有all-profiles目标和active-profiles目标帮助查看项目的Profile。
http://maven.apache.org/plugins/maven-release-plugin/
maven-release-plugin的用途是帮助自动化项目版本发布,它依赖于POM中的SCM信息。
release:prepare用来准备版本发布,具体的工作包括检查是否有未提交代码、检查是否有SNAPSHOT依赖、升级项目的SNAPSHOT版本至RELEASE版本、为项目打标签等等。
release:perform则是签出标签中的RELEASE源码,构建并发布。版本发布是非常琐碎的工作,它涉及了各种检查,而且由于该工作仅仅是偶尔需要,因此手动操作很容易遗漏一些细节。
maven-release-plugin让该工作变得非常快速简便,不易出错。maven-release-plugin的各种目标通常直接在命令行调用,因为版本发布显然不是日常构建生命周期的一部分。
http://maven.apache.org/plugins/maven-resources-plugin/
为了使项目结构更为清晰,Maven区别对待Java代码文件和资源文件,maven-compiler-plugin用来编译Java代码,maven-resources-plugin则用来处理资源文件。
默认的主资源文件目录是src/main/resources
,很多用户会需要添加额外的资源文件目录,这个时候就可以通过配置maven-resources-plugin来实现。
此外,资源文件过滤也是Maven的一大特性,你可以在资源文件中使用${propertyName}形式的Maven属性,然后配置maven-resources-plugin开启对资源文件的过滤,
之后就可以针对不同环境通过命令行或者Profile传入属性的值,以实现更为灵活的构建。
http://maven.apache.org/plugins/maven-surefire-plugin/
可能是由于历史的原因,Maven 2/3中用于执行测试的插件不是maven-test-plugin,而是maven-surefire-plugin。
其实大部分时间内,只要你的测试类遵循通用的命令约定(以Test结尾、以TestCase结尾、或者以Test开头),就几乎不用知晓该插件的存在。
然而在当你想要跳过测试、排除某些测试类、或者使用一些TestNG特性的时候,了解maven-surefire-plugin的一些配置选项就很有用了。
例如 mvn test -Dtest=FooTest 这样一条命令的效果是仅运行FooTest测试类,这是通过控制maven-surefire-plugin的test参数实现的。
http://mojo.codehaus.org/build-helper-maven-plugin/
Maven默认只允许指定一个主Java代码目录和一个测试Java代码目录,虽然这其实是个应当尽量遵守的约定,
但偶尔你还是会希望能够指定多个源码目录(例如为了应对遗留项目),build-helper-maven-plugin的add-source目标就是服务于这个目的,
通常它被绑定到默认生命周期的generate-sources阶段以添加额外的源码目录。需要强调的是,这种做法还是不推荐的,
因为它破坏了 Maven的约定,而且可能会遇到其他严格遵守约定的插件工具无法正确识别额外的源码目录。
build-helper-maven-plugin的另一个非常有用的目标是attach-artifact,
使用该目标你可以以classifier的形式选取部分项目文件生成附属构件,并同时install到本地仓库,也可以deploy到远程仓库。
http://mojo.codehaus.org/exec-maven-plugin/
exec-maven-plugin很好理解,顾名思义,它能让你运行任何本地的系统程序,
在某些特定情况下,运行一个Maven外部的程序可能就是最简单的问题解决方案,这就是exec:exec的用途,当然,该插件还允许你配置相关的程序运行参数。
除了exec目标之外,exec-maven-plugin还提供了一个java目标,该目标要求你提供一个mainClass参数,然后它能够利用当前项目的依赖作为classpath,在同一个JVM中运行该mainClass。
有时候,为了简单的演示一个命令行Java程序,你可以在POM中配置好exec-maven-plugin的相关运行参数,然后直接在命令运行 mvn exec:java 以查看运行效果。
http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin
在进行Web开发的时候,打开浏览器对应用进行手动的测试几乎是无法避免的,这种测试方法通常就是将项目打包成war文件,然后部署到Web容器中,再启动容器进行验证,这显然十分耗时。
为了帮助开发者节省时间,jetty-maven-plugin应运而生,它完全兼容 Maven项目的目录结构,能够周期性地检查源文件,一旦发现变更后自动更新到内置的Jetty Web容器中。
做一些基本配置后(例如Web应用的contextPath和自动扫描变更的时间间隔),你只要执行 mvn jetty:run ,然后在IDE中修改代码,代码经IDE自动编译后产生变更,
再由jetty-maven-plugin侦测到后更新至Jetty容器,这时你就可以直接测试Web页面了。
需要注意的是,jetty-maven-plugin并不是宿主于Apache或Codehaus的官方插件,因此使用的时候需要额外的配置settings.xml
的pluginGroups元素,将org.mortbay.jetty这个pluginGroup加入。
http://mojo.codehaus.org/versions-maven-plugin/
很多Maven用户遇到过这样一个问题,当项目包含大量模块的时候,为他们集体更新版本就变成一件烦人的事情,到底有没有自动化工具能帮助完成这件事情呢?
(当然你可以使用sed之类的文本操作工具,不过不在本文讨论范围)答案是肯定的,versions-maven- plugin提供了很多目标帮助你管理Maven项目的各种版本信息。
例如最常用的,命令 mvn versions:set -DnewVersion=1.1-SNAPSHOT 就能帮助你把所有模块的版本更新到1.1-SNAPSHOT。
该插件还提供了其他一些很有用的目标,display-dependency- updates能告诉你项目依赖有哪些可用的更新;
类似的display-plugin-updates能告诉你可用的插件更新;然后use- latest-versions能自动帮你将所有依赖升级到最新版本。
最后,如果你对所做的更改满意,则可以使用 mvn versions:commit 提交,不满意的话也可以使用 mvn versions:revert 进行撤销。
五、使用案例
① maven-jetty-plugin
http://blog.sina.com.cn/s/blog_62b0363101012he0.html
http://stamen.iteye.com/blog/1933452
输入:mvn jetty:run。这将在端口为8080的Jetty服务器上启动你的项目。Jetty将持续运行,直到插件是明确停止。例如,按下
rop-sample
org.mortbay.jetty
maven-jetty-plugin
6.1.5
src/main/webapp
3
/
8088
② maven-compiler-plugin 编译源代码
在Maven项目下,我们需要配置"maven-compiler-plugin"的"encoding"参数
org.apache.maven.plugins
maven-compiler-plugin
3.1
UTF8
需要在编译和生成的时候使用不同的jdk版本
org.apache.maven.plugins
maven-compiler-plugin
3.5.1
1.7
③ maven-war-plugin
打包war项目的时候排除某些web资源文件,这时就应该配置maven-war-plugin如下:
org.apache.maven.plugins
maven-war-plugin
2.1.1
src/main/webapp
**/*.jpg
④ maven-source-plugin 生成源码包
org.apache.maven.plugins
maven-source-plugin
2.1.2
attach-sources
verify
jar-no-fork
maven-source-plugin
2.1
true
${project.build.sourceEncoding}
compile
jar
⑤ maven-javadoc-plugin 生成javadoc包
org.apache.maven.plugins
maven-javadoc-plugin
2.7
attach-javadocs
jar
⑥ maven-assembly-plugin
它支持各种打包文件格式,包括zip、tar.gz、tar.bz2等等,通过一个打包描述文件(该例中是src/main/assembly.xml),它能够帮助用户选择具体打包哪些文件集合、依赖、模块、和甚至本地仓库文件,每个项的具体打包路径用户也能自由控制。如下就是对应上述需求的打包描述文件src/main/assembly.xml:
bin
zip
true
lib
/
README.txt
src/main/scripts
/bin
run.sh
run.bat
最终生成一个zip格式的分发包,它包含如下的一个结构:
bin/
lib/
README.txt
最后,我们需要配置maven-assembly-plugin使用打包描述文件,并绑定生命周期阶段使其自动执行打包操作:
org.apache.maven.plugins
maven-assembly-plugin
2.2.1
src/main/assembly/assembly.xml
make-assembly
package
single
运行mvn clean package之后,我们就能在target/目录下得到名为hello-world-1.0-bin.zip的分发包了。
⑦ maven-surefire-plugin 打包时跳过单元测试
maven-surefire-plugin
2.6
true
mvn package -Dmaven.test.skip=true
如果单元测试中有输出中文,eclipse的控制台里中文可能会变成乱码输出,也可以通过这个插件解决,参考配置:
org.apache.maven.plugins
maven-surefire-plugin
2.16
once
-Dfile.encoding=UTF-8
⑧ maven-resource-plugin
org.apache.maven.plugins
maven-resources-plugin
2.4.3
compile
${project.build.sourceEncoding}
把web项目的输出copy到tomcat的webapp下
org.apache.maven.plugins
maven-resources-plugin
2.5
deploy-website
package
copy-resources
${server_home}/webapps/${project.build.finalName}
${project.build.directory}/${project.build.finalName}
⑨ maven-dependency-plugin
自动拷贝jar包到target目录
org.apache.maven.plugins
maven-dependency-plugin
2.6
copy-dependencies
compile
copy-dependencies
${project.build.directory}/lib
false
true
在部署war包时,需要将项目依赖的jar包,也打到war包中,因此就会用到上述插件
⑩ 在打包时,需要清空一些指定的目录
在一个J2EE项目中,想使用mvn clean命令清除target里的内容的同时,也清除tomcat/webapp下的相应目录,该怎么办呢?
maven-clean-plugin
true
c:/a/b/c/
本例中,删除的是c:/a/b/c/目录.
当用户在该maven项目中执行mvn clean后,除了删除clean插件默认的
project.build.directory
project.build.outputDirectory
project.build.testOutputDirectory
project.reporting.outputDirectory
c:/a/b/c/
11、利用tomcat-maven-plugin插件将项目自动打包并部署到tomcat中
org.codehaus.mojo
tomcat-maven-plugin
tomcat6-manager
/${project.build.name}
http://localhost:8080/manager
admin
admin
deploy
deploy
path: 是指项目部署到tomcat后的项目名称 url: 是指tomcat的manager访问地址 server: 这个是tomcat服务名称设置,需要配置maven的settings.xml文件,在servers节点中手动配置server,如下所示:
tomcat6-manager
admin
admin
12、利用cargo-maven2-plugin插件将项目自动打包并部署到tomcat中
cargo插件可以帮助你完成WAR包到服务器的部署及服务器的启动和关闭等工作,方便,快速!
org.codehaus.cargo
cargo-maven2-plugin
1.2.0
${server_name}
${server_home}
existing
${server_home}
8088
注意,如果你的tomcat服务器的端口使用的不是默认的8080(如本例中的8088),则需要使用cargo.servlet.port参数将cargo的监听端口也配置到tomcat的那个监听端口(如本例中的8088),否则使用mvn cargo:run启动的服务器会在120000毫秒(120秒)后自动关闭!
mvn cargo:start命令完成WAR包部署后,启动服务器,然后会将服务器立即关掉;
mvn cargo:run命令完成WAR包部署后,启动服务器,直到你Ctrl+C将服务器关掉;
mvn cargo:stop命令关闭服务器。
参考:http://cargo.codehaus.org/Maven2+plugin
org.codehaus.cargo
cargo-maven2-plugin
1.2.3
tomcat6x
E:\Program Files\tomcat-6.0.32
existing
E:\Program Files\tomcat-6.0.32
http://localhost:8080/manager
admin
admin
百度云盘下载连接
链接:https://pan.baidu.com/s/1T6AkkOvJ0RdST08jzNwHbQ
密码:53ui