maven依赖编译

1. 解决 maven 项目无法编译的问题

在使用 Idea 编译 maven 项目时，若遇到错误提示，应检查依赖的 jar 包是否完整下载。

错误提示可能显示为 '无法找到或加载主类' 或者其他与 jar 包缺失相关的信息。

问题通常源于本地 Maven 仓库中 jar 包下载不完全。解决步骤如下：首先，删除本地仓库中存在问题的 jar 包；其次，重新打包项目。

实现这一操作，可以编写 Java 类利用 commons-io 包。具体步骤包括识别问题 jar 包路径，调用 commons-io 方法进行删除，最后通过 Idea 的 'reload' 功能更新项目依赖。

编写步骤如下：

1. 创建 Java 类，导入 commons-io 相关包。

2. 编写方法，通过 Maven 仓库路径和 jar 包名识别问题 jar 包。

3. 使用 commons-io 方法删除识别出的 jar 包。

4. 在 Idea 中执行 'reload'，更新项目依赖。

执行上述步骤后，问题 jar 包应被正确删除，项目重新编译时不应再出现依赖问题。

2. 纯干货！华为软件开发云编译构建之Maven

华为软件开发云中的Maven编译构建是一个基于Maven项目管理和整合工具的自动化构建过程。以下是关于华为软件开发云编译构建之Maven的详细解答：

1. Maven的基本功能与优势： 功能：Maven是一个项目管理和整合工具，提供构建生命周期框架，帮助开发者自动完成基础构建配置，包括管理构建、文档、报告、依赖、版本控制、发布、分发等。 优势：标准化、自动化、高效性，以及强大的可扩展性。通过Maven插件，还能实现代码检查、单元测试覆盖率统计和持续集成等功能。

2. 华为软件开发云中的Maven构建配置： 任务创建：新建构建任务时，需输入任务名称，并选择代码仓库和分支。 归档路径与类型：归档路径和类型应与项目目录结构和pom文件设定一致，确保构建产物的正确归档。 参数配置：在基本信息中设定执行参数，包括包名、版本号、分组和打包类型。代码配置需选择构建仓库和分支，支持自动构建以检测代码变动并触发编译。 构建环境：选择Java和Maven作为构建环境，配置Maven版本、是否发布到私有库、Maven参数以及pom文件路径。 属性与JVM选项：属性配置包含Maven版本管理属性，确保参数无空格，属性间用空格分隔。JVM选项设置用于解决内存溢出问题，可调整PermGen区大小。

3. Maven在华为软件开发云中的构建流程： 构建后参数配置：定义包名、版本号、文件路径、分组和打包类型，多仓库构建时需重复配置。 构建计划配置：提供不定时、每日和每周构建选项，可设置构建时长限制。 执行构建：根据需求填写参数并启动构建，通过Maven实现自动化构建流程。

4. Maven作为依赖管理和项目管理工具的作用： 依赖管理：Maven提供中央仓库自动下载构件的功能，解决依赖增多、版本不一致、冲突和臃肿等问题。通过坐标系统精确定位构件，提供免费的全球中央仓库和快速搜索功能。 项目管理：Maven简化了项目管理流程，提升了开发效率，使开发者能够更专注于业务逻辑的实现。

综上所述，华为软件开发云中的Maven编译构建是一个高效、自动化且可扩展的构建过程，通过Maven的依赖管理和项目管理功能，能够显着提升软件开发的效率和质量。

3. maven依赖＜scope＞作用域详解

1、compile

在不设置scope标签的情况下，默认的作用域是compile。compile表示依赖项目需要参与当前项目的编译，并随后的测试和运行周期也会使用到，这是一种较为严格的依赖类型。在打包时，通常需要将此类依赖包含在内，但请注意，打包还需要插件的支持。

2、test

当scope设置为test时，依赖项目仅参与测试相关的工作，包括测试代码的编译和执行。例如，JUnit就是一个典型的test作用域的依赖。

3、runtime

runtime作用域表示依赖项目不需要参与项目的编译，但会在后续的测试和运行周期中使用。与compile相比，它仅跳过了编译阶段。

4、provided

当依赖项目的scope设置为provided时，它将参与编译，但在打包时不会将其包含在内。这意味着，如果其他项目需要引用这个依赖，引用的项目必须包含该依赖的相应scope，否则可能会出现问题。

5、system

当依赖项的scope设置为system时，它不会从maven仓库抓取，而是从本地文件系统获取，需要配合systemPath属性一起使用。

4. maven依赖范围及依赖传递

maven依赖范围是用于控制依赖与三种classpath（编译、测试、运行）之间的关系，maven提供了以下几种依赖范围：

compile：编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的maven依赖，对于编译、测试、运行三种classpath都有效。典型的例子是spring-core，在编译、测试、运行时都需要使用该依赖。

test：测试依赖范围。使用此依赖范围的maven依赖，只对测试classpath有效，在编译主代码或运行项目时无法使用此类依赖。典型的例子就是junit，它只有在编译测试代码及运行测试时才需要。

provided：已提供依赖范围。使用此依赖范围的maven依赖对于编译和测试classpath有效，在运行时无效。典型的例子是servlet-api，编译和测试项目时需要该依赖，但在运行时容器已经提供，就不需要重复引入了。

runtime：运行时依赖范围。使用此依赖范围的maven依赖对于测试和运行classpath有效，但在编译主代码时无效。典型的例子是JDBC的驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或运行项目时才需要实现上述接口的具体JDBC驱动。

system：系统依赖范围。该范围与三种classpath的关系和provided依赖范围完全一致。但是使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此依赖不是通过maven仓库解析而且与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。systemPath元素可以引用环境变量。

import：导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。

依赖范围与classpath的关系如下：

maven引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另一方面，大部分情况下我们只需要关心项目的直接依赖是什么，而不用考虑这些直接依赖会引入什么传递性依赖。但有时候，当传递性依赖造成问题时，我们就需要清楚地知道该传递性依赖是从哪条依赖路径引入的。

例如，项目A有这样的依赖关系：A-->B-->C-->X(1.0)、A-->D-->X(2.0)，X是A的传递性依赖，但是两条依赖路径上有两个版本的X，那么哪个X会被maven解析使用呢？两个版本都被解析显然是不对的，因为那会造成依赖重复，因此必须选择一个。maven依赖调解的第一原则：路径最近者优先。该例中X(1.0)的路径长度为3，而X(2.0)的路径长度为2，因此X(2.0)会被解析使用。

依赖调解第一原则不能解决所有问题，比如这样的依赖关系：A-->B-->Y(1.0)，A-->C-->Y(2.0)，Y(1.0)和Y(2.0)的依赖路径长度是一样的，都为2。那么到底谁会被解析使用呢？在maven2.0.8及之前的版本中，这是不确定的，但是maven2.0.9开始，为了尽可能避免构建的不确定性，maven定义了依赖调解的第二原则：第一声明者优先。在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用。顺序最靠前的那个依赖优先。