管理工具---Maven系列(零)Maven

拿来即用主义

记得把本地仓库位置改为自己的库位置

<?xml version="1.0" encoding="UTF-8" ?>
 
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at
    http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
-->
 
<!--
 | This is the configuration file for Maven. It can be specified at two levels:
 |
 |  1. User Level. This settings.xml file provides configuration for a single user,
 |                 and is normally provided in ${user.home}/.m2/settings.xml.
 |
 |                 NOTE: This location can be overridden with the CLI option:
 |
 |                 -s /path/to/user/settings.xml
 |
 |  2. Global Level. This settings.xml file provides configuration for all Maven
 |                 users on a machine (assuming they're all using the same Maven
 |                 installation). It's normally provided in
 |                 ${maven.home}/conf/settings.xml.
 |
 |                 NOTE: This location can be overridden with the CLI option:
 |
 |                 -gs /path/to/global/settings.xml
 |
 | The sections in this sample file are intended to give you a running start at
 | getting the most out of your Maven installation. Where appropriate, the default
 | values (values used when the setting is not specified) are provided.
 |
 |-->
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <!-- localRepository
     | The path to the local repository maven will use to store artifacts.
     |
     | Default: ${user.home}/.m2/repository
    <localRepository>/path/to/local/repo</localRepository>
    -->
    <!--自定义本地仓库路径-->
    <localRepository>E:\JAVA\Maven</localRepository>
    <!-- interactiveMode
     | This will determine whether maven prompts you when it needs input. If set to false,
     | maven will use a sensible default value, perhaps based on some other setting, for
     | the parameter in question.
     |
     | Default: true
    <interactiveMode>true</interactiveMode>
    -->
 
    <!-- offline
     | Determines whether maven should attempt to connect to the network when executing a build.
     | This will have an effect on artifact downloads, artifact deployment, and others.
     |
     | Default: false
    <offline>false</offline>
    -->
 
    <!-- pluginGroups
     | This is a list of additional group identifiers that will be searched when resolving plugins by their prefix, i.e.
     | when invoking a command line like "mvn prefix:goal". Maven will automatically add the group identifiers
     | "org.apache.maven.plugins" and "org.codehaus.mojo" if these are not already contained in the list.
     |-->
    <pluginGroups>
        <!-- pluginGroup
         | Specifies a further group identifier to use for plugin lookup.
        <pluginGroup>com.your.plugins</pluginGroup>
        -->
    </pluginGroups>
 
    <!-- proxies
     | This is a list of proxies which can be used on this machine to connect to the network.
     | Unless otherwise specified (by system property or command-line switch), the first proxy
     | specification in this list marked as active will be used.
     |-->
    <proxies>
        <!-- proxy
         | Specification for one proxy, to be used in connecting to the network.
         |
        <proxy>
          <id>optional</id>
          <active>true</active>
          <protocol>http</protocol>
          <username>proxyuser</username>
          <password>proxypass</password>
          <host>proxy.host.net</host>
          <port>80</port>
          <nonProxyHosts>local.net|some.host.com</nonProxyHosts>
        </proxy>
        -->
    </proxies>
 
    <!-- servers
     | This is a list of authentication profiles, keyed by the server-id used within the system.
     | Authentication profiles can be used whenever maven must make a connection to a remote server.
     |-->
    <servers>
        <!-- server
         | Specifies the authentication information to use when connecting to a particular server, identified by
         | a unique name within the system (referred to by the 'id' attribute below).
         |
         | NOTE: You should either specify username/password OR privateKey/passphrase, since these pairings are
         |       used together.
         |
        <server>
          <id>deploymentRepo</id>
          <username>repouser</username>
          <password>repopwd</password>
        </server>
        -->
 
        <!-- Another sample, using keys to authenticate.
        <server>
          <id>siteServer</id>
          <privateKey>/path/to/private/key</privateKey>
          <passphrase>optional; leave empty if not used.</passphrase>
        </server>
        -->
    </servers>
 
    <!-- mirrors
     | This is a list of mirrors to be used in downloading artifacts from remote repositories.
     |
     | It works like this: a POM may declare a repository to use in resolving certain artifacts.
     | However, this repository may have problems with heavy traffic at times, so people have mirrored
     | it to several places.
     |
     | That repository definition will have a unique id, so we can create a mirror reference for that
     | repository, to be used as an alternate download site. The mirror site will be the preferred
     | server for that repository.
     |-->
    <mirrors>
        <!-- mirror
         | Specifies a repository mirror site to use instead of a given repository. The repository that
         | this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used
         | for inheritance and direct lookup purposes, and must be unique across the set of mirrors.
         |
        <mirror>
          <id>mirrorId</id>
          <mirrorOf>repositoryId</mirrorOf>
          <name>Human Readable Name for this Mirror.</name>
          <url>http://my.repository.com/repo/path</url>
        </mirror>
         -->
 
        <mirror>
            <id>alimaven-central</id>
            <mirrorOf>central</mirrorOf>
            <name>aliyun maven</name>
            <url>http://maven.aliyun.com/nexus/content/repositories/central/</url>
        </mirror>
        <mirror>
            <id>jboss-public-repository-group</id>
            <mirrorOf>central</mirrorOf>
            <name>JBoss Public Repository Group</name>
            <url>http://repository.jboss.org/nexus/content/groups/public</url>
        </mirror>
 
        <!--<mirror>
            <id>alimaven</id>
            <name>aliyun maven</name>
            <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
            <mirrorOf>central</mirrorOf>
        </mirror>
        <mirror>
            <id>ibiblio</id>
            <mirrorOf>central</mirrorOf>
            <name>Human Readable Name for this Mirror.</name>
            <url>http://mirrors.ibiblio.org/pub/mirrors/maven2/</url>
        </mirror>
        <mirror>
            <id>central</id>
            <name>Maven Repository Switchboard</name>
            <url>http://repo1.maven.org/maven2/</url>
            <mirrorOf>central</mirrorOf>
        </mirror>
        <mirror>
            <id>repo2</id>
            <mirrorOf>central</mirrorOf>
            <name>Human Readable Name for this Mirror.</name>
            <url>http://repo2.maven.org/maven2/</url>
        </mirror>-->
 
    </mirrors>
 
    <!-- profiles
     | This is a list of profiles which can be activated in a variety of ways, and which can modify
     | the build process. Profiles provided in the settings.xml are intended to provide local machine-
     | specific paths and repository locations which allow the build to work in the local environment.
     |
     | For example, if you have an integration testing plugin - like cactus - that needs to know where
     | your Tomcat instance is installed, you can provide a variable here such that the variable is
     | dereferenced during the build process to configure the cactus plugin.
     |
     | As noted above, profiles can be activated in a variety of ways. One way - the activeProfiles
     | section of this document (settings.xml) - will be discussed later. Another way essentially
     | relies on the detection of a system property, either matching a particular value for the property,
     | or merely testing its existence. Profiles can also be activated by JDK version prefix, where a
     | value of '1.4' might activate a profile when the build is executed on a JDK version of '1.4.2_07'.
     | Finally, the list of active profiles can be specified directly from the command line.
     |
     | NOTE: For profiles defined in the settings.xml, you are restricted to specifying only artifact
     |       repositories, plugin repositories, and free-form properties to be used as configuration
     |       variables for plugins in the POM.
     |
     |-->
    <profiles>
        <!-- profile
         | Specifies a set of introductions to the build process, to be activated using one or more of the
         | mechanisms described above. For inheritance purposes, and to activate profiles via <activatedProfiles/>
         | or the command line, profiles have to have an ID that is unique.
         |
         | An encouraged best practice for profile identification is to use a consistent naming convention
         | for profiles, such as 'env-dev', 'env-test', 'env-production', 'user-jdcasey', 'user-brett', etc.
         | This will make it more intuitive to understand what the set of introduced profiles is attempting
         | to accomplish, particularly when you only have a list of profile id's for debug.
         |
         | This profile example uses the JDK version to trigger activation, and provides a JDK-specific repo.
        <profile>
          <id>jdk-1.4</id>
          <activation>
            <jdk>1.4</jdk>
          </activation>
          <repositories>
            <repository>
              <id>jdk14</id>
              <name>Repository for JDK 1.4 builds</name>
              <url>http://www.myhost.com/maven/jdk14</url>
              <layout>default</layout>
              <snapshotPolicy>always</snapshotPolicy>
            </repository>
          </repositories>
        </profile>
        -->
        <profile>
            <id>jdk18</id>
            <activation>
                <jdk>1.8</jdk>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <maven.compiler.source>1.8</maven.compiler.source>
                <maven.compiler.target>1.8</maven.compiler.target>
                <maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
            </properties>
        </profile>
 
        <!--
         | Here is another profile, activated by the system property 'target-env' with a value of 'dev',
         | which provides a specific path to the Tomcat instance. To use this, your plugin configuration
         | might hypothetically look like:
         |
         | ...
         | <plugin>
         |   <groupId>org.myco.myplugins</groupId>
         |   <artifactId>myplugin</artifactId>
         |
         |   <configuration>
         |     <tomcatLocation>${tomcatPath}</tomcatLocation>
         |   </configuration>
         | </plugin>
         | ...
         |
         | NOTE: If you just wanted to inject this configuration whenever someone set 'target-env' to
         |       anything, you could just leave off the <value/> inside the activation-property.
         |
        <profile>
          <id>env-dev</id>
          <activation>
            <property>
              <name>target-env</name>
              <value>dev</value>
            </property>
          </activation>
          <properties>
            <tomcatPath>/path/to/tomcat/instance</tomcatPath>
          </properties>
        </profile>
        -->
    </profiles>
 
    <!-- activeProfiles
     | List of profiles that are active for all builds.
     |
    <activeProfiles>
      <activeProfile>alwaysActiveProfile</activeProfile>
      <activeProfile>anotherAlwaysActiveProfile</activeProfile>
    </activeProfiles>
    -->
</settings>
 

谈一谈Maven

与maven相关的构建管理工具

make

make由一个名为makefile的脚本文件驱动。make通过一系列目标和依赖将整个构建过程串联起来,同时可利用本地命令完成每个目标的实际行为。
强大的优势:

  1. 可以利用所有系统的本地命令,尤其是UNIX/Linux系统,丰富的功能,强大的命令可以快速帮助Make高效完成任务。

缺点:

  1. 由于以来Linux/unix系统,所以不能跨平台,对于Java不友好。
  2. 语法经常回因为空格或者tab健导致使用错误无法编译。

Ant

Ant不是指蚂蚁,而是指另一个整洁的工具(Another Neat Tool).可以简单的理解ant是Java版本的make,也正因为有了java,所以ant是跨平台的。
与make相似,ant有一个构建脚本build.xml
build.xml的基本结构是目标(target)依赖(depends),以及实现目标的任务。
优势:

  1. 针对于make来说,使用Java的时候,跨平台的优势

缺点:

  1. 针对于maven来说,ant和make都属于过程式(必须每一次都按照目标-》依赖-》任务去配置,比较繁琐),而maven属于声明式(项目的构建过程和过程的各个阶段所需的工作都由插件来实现,并且大部分插件都是现成的)

Maven三大特性:

  • 依赖
  • 仓库
  • 插件

1、依赖

  • 如下因素:
  • groupId
  • artifactId
  • version

第一部分,pom文件第一个配置内容版本:

 <modelVersion>4.0.0</modelVersion>
	<groupId>org.springframework.samples</groupId>
	<artifactId>com.xcxyz.lxc</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<packaging>war</packaging>
  • 特别说明:<version>0.0.1-SNAPSHOT</version>
    第一个数字是总版本号-----框架的变动eg:struts1-----struts2
    第二个数字是分支版本号----增加了哪些功能
    第三个数字是小版本号-----修复了某些bug
    第四个-里程碑版本-----快照版本(开发SNAPSHOT)
    -------测试版本----beta(公测版本)----release、bundle(可以使用)----GA(商用)
    0.0.1-SNAPSHOT----0.0.1release----1.0.0SNAPSHOT
    -------0.1.0SNAPSHOT—0.1.0release-1.1.0SNAPSHOT
    scope—runtime–运行
    compile–默认
    test–测试

1.1依赖的特性:

  • 如果同时依赖的话路径最短为主依赖
  • 如果路径相同,则第一次依赖的为主依赖
  • 依赖中出现冲突,则可以在自己依赖中排出依赖,举例如下:
<!-- SPRING begin -->
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-core</artifactId>
			<version>${spring.version}</version>
			<exclusions>
				<exclusion>
					<groupId>commons-logging</groupId>
					<artifactId>commons-logging</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

1.2聚合打包

<packaging>pom</packaging>
	<url>http://maven.apache.org</url>

	<modules>
		<module>Common</module>
		<module>Service</module>
		<module>Facade</module>
		<module>Web</module>
	</modules>

1.3继承`

<parent>
		<groupId>org.base</groupId>
		<artifactId>Base</artifactId>
		<version>1.1.0</version>
	</parent>

1.4relativePath是父类pom.xml的相对路径
1.5父类里面dependencyManager

  • 子类可以选择继承dependency

2、仓库

2.1私有仓库:

  • nexus安装:

2.2host的仓库

  • Release:内部的模块中release的发布仓库
  • SNAPSHOT:内部开发快照版本仓库
  • 3rd Party:第三方仓库----内部开发人员下载下来发布上去。
  • -----proxy的仓库,从远程仓库中获取数据的仓库。
  • -----group主仓库----方便开发人员来进行设置

3、插件

  • 可以内置多个插件例如tomcat服务器,数据库等等。

~/.m2的介绍

  1. 简单命令:mvn help:system
  2. 两个重要的内容:settings.xml和repository
  3. 公司安全访问:settings.xml设置http的proxy代理。

maven的使用和坐标阐述

  1. 编写pom
<?xml version="1.0" encoding="UTF-8"?>
<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>com.xiaoju.sail.keel</groupId>
    <artifactId>keel</artifactId>
    <version>keel-1.0-SNNAPSHOT</version>
    <name>keel</name>
    <packaging>jar/war</packaging>
</project>
  • groupId定义了项目属于哪个组–通常和公司或者组织相关,通常与域名反向一一对应
  • artificatId定义了项目在组中的唯一一个ID
  • version代表了版本号:针对于版本号如下可能值
    • keel-1.0.0
    • keel-1.1-alpha-4
    • keel-2.0
    • keel-2.1-SNAPSHOT
    • keel-2.1-20091214.2214-13
  • (>ω<)稳定的版本号(发布版):keel-1.0.0,keel-1.1-alpha-4,keel-2.0
  • (///▽///)不稳定的版本号(快照版本):keel-2.1-SNAPSHOT,keel-2.1-20200110.221414-13(含义是什么呢?2020年1月10日22点14分14秒第13次发布)maven默认每天定时更新依赖,也可以手动更新maven依赖
  • modelVersion指定了当前POM模型的版本
  • 项目中没有packaging的话怎么办呢?比如springboot采用了maven-assembly-plugin
  1. 编写主代码
  • maven构建:mvn clean compile
    • clean告诉maven清理输出目录target内容
    • compile告诉maven编译项目主代码
    • resource:resources(处理项目资源文件)
    • compiler:compile将项目的主代码编译至target/classes目录下
  1. 编写测试代码
  • Junit使用:maven项目的默认主代码目录是src/main/java,默认的测试代码目录是src/test/java。因此在编写测试用力之前应该先创建该测试目录。
<dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${junit.version}</version>
            <type>jar</type>默认就是jar所以平时不用写
            <scope>test</scope>
            <optional>true/false</optional>标记依赖是否可选
            <exclusions></exclusions>标记排除冲突的依赖
        </dependency>
    • 上面的scope表明依赖范围,
    • 若填写test表明只针对测试有效,比如junit
    • 如果不填写,则默认值就是compile表示该依赖对主代码和测试代码都有效,比如Spring-core
    • runtime表明运行时候的依赖,对于测试和运行class-path有效,但在编译主代码无效。比如jdbc驱动实现
    • system系统依赖范围,该依赖与三种class-path的关系和provided依赖范围完全一致。但是使用system范围的依赖时候必须通过systemPath元素显式指定依赖文件的路径。由于不通过maven仓库解析而是依赖本机系统,所以谨慎使用。比如maven仓库之外的类库文件
    • provided已经提供的以来范围,编译和测试有效,运行无效,比如servlet-api.
    • import导入依赖范围,该以来范围不会对三种class-path产生实际影响
  • 【补充】编译class-path,测试class-path,运行class-path
  • 单元测试的三个步骤执行命令行mvn clean test:
    • 准备测试类及数据
    • 执行要测试的行为
    • 检查结果—(通常使用断言)
  • 【重要】由于历史原因,maven的核心插件之一compile插件默认只支持编译Java1.3,所以现在的Java版本比较高都需要增加插件配置。
<plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                    <compilerArgument>-parameters</compilerArgument>
                </configuration>
</plugin>
  1. 打包和运行
  • mvn clean package将打包的内容输出到target目录下
  • mvn clean install将输出target目录下的classes文件打包成jar包供其他项目调用
  • mvn clean deploy site-deploy
  • 【总结】mvn clean -》comiple->test->package->install->deploy site-deploy
  • mvn clean install生成jar包,我们如果想直接运行,则需要打开jar文件中的META-INF/MANIFEST.MF文件,将无法看到Main-Class.所以需要在pom文件中借助maven-shade-plugin插件
  1. 使用Archetype生成项目骨架
  • 可以通过ide生成,也可以通过maven命令行,maven版本3使用方式:mvn archetype:generate
  • maven版本2使用方式:mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-5:generate
  1. idea工具中maven的使用

maven依赖讲解

  1. 传递性依赖
  2. 依赖最近者优先-》第一声明者优先
  3. 可选依赖—为了提供多种类型的多元化支持,使用者需要显示声明(可选依赖不被传递)
  4. 排除依赖冲突项
  5. 归类依赖–比如Spring统一使用一个版本号
  6. 优化依赖:
    * mvn dependency:list查看当前项目的依赖项,
    * mvn dependency:tree查看当前项目的依赖树
    * mvn dependency:analyze分析使用但未声明的依赖与声明但未使用的依赖

maven仓库

本地仓库,远程仓库的关系,远程仓库又分为-私服,中央仓库,其他仓库

在这里插入图片描述

maven如何构建jar包的流程解析依赖的机制

在这里插入图片描述

  1. 当maven依赖范围scope=system,maven直接从本地文件系统解析
  2. 当根据依赖坐标计算仓库路径后,尝试直接从本地仓库寻找解析,如果发现则成功
  3. 本地仓库不存在的清咖滚下,如果依赖的版本号是显示的发布版本构件,如1.2,2.1-beta-1等,则遍历所有的远程仓库,发现后,下载并解析使用
  4. 如果依赖的版本是RELEASE或者LATEST,则基于更新策略读取所有远程仓库的元数据groupId/artifactId/version/maven-metadata.xml,将与本地仓库的对应元数据合并后,得到最新的快照版本的值,然后基于该值检查本地仓库,或者从远程仓库下载。
  5. 如果依赖的版本是SNAPSHOT,则基于更新策略读取所有远程仓库的元数据groupId/artifactId/version/maven-metadata.xml,将与本地仓库的对应元数据合并后,得到最新的快照版本的值,然后基于该值检查本地仓库,或者从远程仓库下载。
  6. 如果最后解析得到的构建版本是时间戳格式的快照,如1.4.1-20200110.121450-13则复制其时间戳格式的文件至非时间戳格式,如SNAPSHOT,并使用该时间戳格式的构建

为什么要用私服

  • 节省自己的外网带宽
  • 加速maven构建
  • 部署第三方构件
  • 提高稳定性,增强控制
  • 降低中央仓库的负荷

配置使用私服作为镜像,来加快访问速度,私服可以代理任何外部的公共仓库(包括中央仓库)

<mirrorsOf>*</mirrors>匹配所有远程仓库
<mirrorsOf>external:*</mirrors>匹配所有不再本机上的远程仓库
<mirrorsOf>repo1,repo2</mirrors>匹配仓库repo1和repo2,使用逗号分割多个远程仓库
<mirrorsOf>*,!repo1</mirrors>匹配所有远程仓库,repo1除外

【提示】由于镜像仓库完全屏蔽了被镜像仓库,当镜像仓库不稳定或者停止服务的时候,maven仍然将无法访问被镜像仓库,因而无法下载构件

仓库搜索服务:
nexus/jarvana/mvnbrowser/mvnrepository

maven的生命周期和插件

maven的生命周期是抽象的,其实际行为都是由插件来完成的。
一个项目的生命周期包括如下几步:
项目的清理,初始化,编译,测试,打包,集成测试,验证,部署,站点生成等几乎所有构建步骤。而这些步骤映射到一个生命周期上。

生命周期和插件的关系:

在这里插入图片描述

maven的三套生命周期

clean生命周期

  • pre-clean执行一些清理前需要完成的工作
  • clean清理上一次构建生成的文件
  • post-clean执行一些清理后需要完成的工作

default生命周期

  • validate(校验)
  • initialize(初始化)
  • generate-sources(生成资源)
  • process-sources处理项目主资源文件一般来说,是对src/main/resources目录的内容进行变量替换等工作后,复制到项目输出的主classpath目录中
  • generate-resources
  • process-resources
  • compile编译项目的主源码,一般来说是编译src/main/java目录下的Java文件至项目输出的主classpath目录中
  • process-classes
  • generate-test-sources
  • process-test-sources处理项目测试资源文件,一般来说,是对src/test/resources目录的内容进行变量替换等工作后,复制到项目输出的测试class path目录中
  • generate-test-resources
  • process-test-resources
  • test-compile编译项目的测试代码。一般来说,是编译src/test/java目录下的Java文件至项目输出的测试classpath目录中
  • process-test-classes
  • test使用单元测试框架运行测试,测试代码不会被打包或者被部署
  • prepare-package
  • package接受编译好的代码,打包成可发布的格式如jar
  • pre-integration-test
  • integration-test
  • post-integration-test
  • verify
  • install将包安装到maven本地仓库,供本地其他maven项目使用

site生命周期

  • pre-site执行一些在生成项目站点之前需要完成的工作
  • site生成项目站点文档
  • post-site执行一些在生成项目站点之后需要完成的工作
  • site-deploy将生成的项目站点发布到服务器上。

###maven的插件化对于插件系统的思考:
插件目标:

  • 每个功能都应该成为一个插件–类似模版

插件绑定:

  • maven的生命周期与插件相互绑定,用以完成实际的构建任务

内置绑定:

  • 用户不需要关心的东西封装起来

自定义绑定:

  • 动态可配置化

在线的插件信息

  • 动态可获取

插件的解析

  • 约定大于配置(简化学习的成本和错误)

maven的聚合与继承

聚合pom,父pom
反应堆—》类似依赖树:解析构建顺序-》裁剪反应堆

持续继承Hudson/jenkins

持续集成的作用,过程和优势

  • 快速
  • 高频率
  • 自动
  • 构建
  • 所有源码
  • 反馈

一次集成包括的步骤:

  1. 持续编译
  2. 持续数据库集成
  3. 持续测试
  4. 持续审查
  5. 持续部署
  6. 持续反馈

好处:
尽早暴露问题,减少重复操作,简化项目发布,建立团队信心

如何编写一个maven插件

  1. 创建一个maven-plugin项目:插件本身也是一个maven项目,特殊的地方在于packaging必须是maven-plugin,用户可以使用maven-archetype-plugin快速创建一个maven插件项目。
  2. 为插件编写目标:每个插件都必须有一个或者多个目标,maven称之为Mojo与POJO对应,编写插件的时候必须提供一个或者多个继承自AbstractMojo的类
  3. 为目标提供配置点:
  4. 编写代码实现目标行为:根据实际需要实现Mojo
  5. 错误处理以及日志:当Mojo发生异常,根据情况控制maven的运行状态
  6. 测试插件:编写自动化的测试代码测试行为,然后实际运行插件以验证其行为。

eg:实现用于代码行统计的maven插件
mvn archetype:generate
然后选择
maven-archetype:plugin
代码地址:http://www.juvenxu.com/mvn-in-action

发布了210 篇原创文章 · 获赞 243 · 访问量 26万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 护眼 设计师: 闪电赇

分享到微信朋友圈

×

扫一扫,手机浏览