[实习]Maven（updating）

最新推荐文章于 2024-06-19 07:44:47 发布

Azhang_

最新推荐文章于 2024-06-19 07:44:47 发布

阅读量263

点赞数

分类专栏：实习 java学习

本文链接：https://blog.csdn.net/Azhang_/article/details/111478555

版权

java学习同时被 2 个专栏收录

19 篇文章 0 订阅

订阅专栏

实习

12 篇文章 0 订阅

订阅专栏

实习的时候遇到了一些情况，对于maven很不熟悉，希望在这边能记录一些关于maven的学习心得

MAVEN指令与生命周期

首先一个maven project能不能过不是靠直接run的，一般是通过用maven指令来操作。maven build的生命周期主要如下图所示
在这里插入图片描述

阶段	处理	描述
验证 validate	验证项目	验证项目是否正确且所有必须信息是可用的
编译 compile	执行编译	源代码编译在此阶段完成
测试 Test	测试	使用适当的单元测试框架（例如JUnit）运行测试
包装 package	打包	创建JAR/WAR包如在 pom.xml 中定义提及的包
检查 verify	检查	对集成测试的结果进行检查，以保证质量达标
安装 install	安装	安装打包的项目到本地仓库，以供其他项目使用
部署 deploy	部署	拷贝最终的工程包到远程仓库中，以共享给其他开发人员和工程

Maven 有以下三个标准的生命周期：

clean：项目清理的处理
default(或 build)：项目部署的处理
site：项目站点文档创建的处理

这里说一点使用 mvn 指令的时候，比如 mvn deploy会把之前所有的生命周期都走一遍从validate到install都运行后才会deploy。而在package的时候会生成包，但是如果不加强制覆盖的参数的话，第二次直接调用deploy不会覆盖之前的包，即不会更新。而用clean会移除所有上一次构建生成的文件，等于重构整个生命周期。缺点是所消耗的时间会多一些。

mvn deploy

这个指令主要功能是拷贝最终的工程包到远程仓库中，以共享给其他开发人员和工程

并不是所有project都需要deploy的
也可以说如果这个project是一个单独的服务，并且它并不需要对外提供lib包，供人import，那么它其实是没必要 deploy的。(比如我做的一个项目就是consumer从消息队列把消息取出来转存到druid中，这个过程的操作其实就是一个单独的服务，并且逻辑上来说外面也不会导入，那么就不需要deploy)

此外提一嘴，如果要deploy，在pom里需要设置仓库，一般的形式如：

<distributionManagement>
	<repository>
        <id>central</id>
        <name>maven-release-virtual</name>
        <url> xxx </url>
    </repository>
    <snapshotRepository>
        <id>snapshots</id>
        <name>maven-snapshot-virtual</name>
        <url> xxx </url>
    </snapshotRepository>
</distributionManagement>

默认情况下，不管Linux还是 Windows，每个用户在自己的用户目录下都有一个路径名为 .m2/respository/ 的仓库目录。
Maven 本地仓库默认被创建在 %USER_HOME% 目录下。要修改默认位置，在 %M2_HOME%\conf 目录中的 Maven 的 settings.xml 文件中定义另一个路径。

注意事项

pom.xml中distributionManagement中相关的仓库ID要与settings保持一致
清空本地的cache
对于IDE（尤其是intelijj idea）确保settings是否生效

仓库从功能来说区分为三种：本地（local），中央（central），远程（remote）

1. local

Maven 的本地仓库，在安装 Maven 后并不会创建，它是在第一次执行 maven 命令的时候才被创建。

运行 Maven 的时候，Maven 所需要的任何构件都是直接从本地仓库获取的。如果本地仓库没有，它会首先尝试从远程仓库下载构件至本地仓库，然后再使用本地仓库的构件。

2. Central

Maven 中央仓库是由 Maven 社区提供的仓库，其中包含了大量常用的库。

中央仓库包含了绝大多数流行的开源Java构件，以及源码、作者信息、SCM、信息、许可证信息等。一般来说，简单的Java项目依赖的构件都可以在这里下载到。

中央仓库的关键概念：

这个仓库由 Maven 社区管理。
不需要配置。
需要通过网络才能访问。

3. Remote

如果 Maven 在中央仓库中也找不到依赖的文件，它会停止构建过程并输出错误信息到控制台。为避免这种情况，Maven 提供了远程仓库的概念，它是开发人员自己定制仓库，包含了所需要的代码库或者其他工程中用到的 jar 文件。

Maven依赖顺序

当我们执行 Maven 构建命令时，Maven 开始按照以下顺序查找依赖的库：

步骤 1 －在本地仓库中搜索，如果找不到，执行步骤 2，如果找到了则执行其他操作。
步骤 2 －在中央仓库中搜索，如果找不到，并且有一个或多个远程仓库已经设置，则执行步骤 4，如果找到了则下载到本地仓库中以备将来引用。
步骤 3 －如果远程仓库没有被设置，Maven 将简单的停滞处理并抛出错误（无法找到依赖的文件）。
步骤 4 －在一个或多个远程仓库中搜索依赖的文件，如果找到则下载到本地仓库以备将来引用，否则 Maven 将停止处理并抛出错误（无法找到依赖的文件）。

一些关于上线出现的问题

首先上线的步骤是在对应的cluster里面找到一个节点，在节点上进行部署任务。拿我做的经验作为例子，当时我需要部署的cluster里面有8个节点，他会先实例化一个容器（一个全新节点），这样子节点数会变成9，并分配ip地址。如果这个节点部署成功了，那么会在这个节点部署完毕之后才把先前的节点给删掉。同时其他节点也是依次重启，跟新节点做联结。做法也是起一个，成功一个先前的就关掉。

这里记录一下我当时的操作步骤。首先将需要的版本push到git上，之后通过上线流程审批以后发布版本。然后选择一个cluster，选择我需要发布的版本进行发布。在发布之后如果出现异常会中断，没异常会停住，点继续发布才会真正上线。如果出问题进入调试模式。打开secureCRT，输入对应的镜像容器的ip地址，在对应打印日志的地方查看日志信息。

而在发布的时候会有许多问题，最大的问题就跟maven的依赖有关。比如NoDefClass,ClassNotFound之类的基本都跟maven冲突有关。解决方法是进入对应project的pom.xml，在idea左下角的dependency analyzer里面查看conflict tree。因为新修改项目引入新的依赖，他可能也会带来它自己的依赖。根据依赖的优先级设定就可能会导致新来的包取代了之前，导致之前的部分功能失效。

依赖优先级：