Maven必要知识

已于 2023-05-12 09:20:05 修改
阅读量557 收藏 1
点赞数 1
分类专栏： # Maven 文章标签： maven
于 2023-05-11 16:50:36 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/FuTian0715/article/details/130621665
版权

参考笔记：

http://heavy_code_industry.gitee.io/code_heavy_industry/pro002-maven/

https://www.wolai.com/arAiYJYCr6Kkfi2kZ8HxE8

1. Maven 概述

1.1 什么是 Maven

Maven 是 Apache 软件基金会组织维护的一款专门为 Java 项目提供构建和依赖管理支持的工具。
在这里插入图片描述

  • Maven 作为依赖管理工具
    • jar 包的管理
    • jar 包的来源
    • jar 包之间的依赖关系
  • Maven 作为构建管理工具
    • 脱离IDE环境进行构建
      使用maven命令进行构建
    • 使用IDE环境进行构建
      使用IDEA等集成开发环境进行配置并构建

1.2 构建

1.2.1 Java 项目开发过程中，构建指的是使用『原材料生产产品』的过程：

  • 原材料
    • Java 源代码
    • 基于 HTML 的 Thymeleaf 文件
    • 图片
    • 配置文件
    • ……
  • 产品
    • 一个可以在服务器上运行的项目

1.2.2 构建过程包含的主要的环节：

  • 清理：删除上一次构建的结果，为下一次构建做好准备
  • 编译：Java 源程序编译成 *.class 字节码文件
  • 测试：运行提前准备好的测试程序
  • 报告：针对刚才测试的结果生成一个全面的信息
  • 打包
    • Java工程：jar包
    • Web工程：war包
  • 安装：把一个 Maven 工程经过打包操作生成的 jar 包或 war 包存入Maven的本地仓库
  • 部署
    • 部署 jar 包：把一个 jar 包部署到 Nexus 私服服务器上
    • 部署 war 包：借助相关 Maven 插件（例如 cargo），将 war 包部署到 Tomcat 服务器上

1.3 依赖

如果 A 工程里面用到了 B 工程的类、接口、配置文件等等这样的资源，那么我们就可以说 A 依赖 B。例如：

  • junit-4.12 依赖 hamcrest-core-1.3
  • thymeleaf-3.0.12.RELEASE 依赖 ognl-3.1.26
    • ognl-3.1.26 依赖 javassist-3.20.0-GA
  • thymeleaf-3.0.12.RELEASE 依赖 attoparser-2.0.5.RELEASE
  • thymeleaf-3.0.12.RELEASE 依赖 unbescape-1.1.6.RELEASE
  • thymeleaf-3.0.12.RELEASE 依赖 slf4j-api-1.7.26

依赖管理中要解决的具体问题：

  • jar 包的下载：使用 Maven 之后，jar 包会从规范的远程仓库下载到本地
  • jar 包之间的依赖：通过依赖的传递性自动完成
  • jar 包之间的冲突：通过对依赖的配置进行调整，让某些jar包不会被导入

1.4 Maven 的工作机制

在这里插入图片描述

2. Maven 的配置与应用

2.1 Maven 配置与环境变量

2.1.1 Maven 官网地址与下载

首页：
Maven – Welcome to Apache Maven(opens new window)

下载页面：
Maven – Download Apache Maven(opens new window)
在这里插入图片描述

2.1.2 Maven 的目录结构

在这里插入图片描述

在解压目录中，我们需要着重关注 Maven 的核心配置文件：conf/settings.xml

2.1.3 指定 Maven 的本地仓库

本地仓库默认值：用户家目录/.m2/repository。由于本地仓库的默认位置是在用户的家目录下，而家目录往往是在 C 盘，也就是系统盘。将来 Maven 仓库中 jar 包越来越多，仓库体积越来越大，可能会拖慢 C 盘运行速度，影响系统性能。所以建议将 Maven 的本地仓库放在其他盘符下。修改Maven 的核心配置文件：conf/settings.xml，配置方式如下：

<!-- 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>D:\maven-repository</localRepository>

本地仓库这个目录，我们手动创建一个空的目录即可。
记住：一定要把 localRepository 标签从注释中拿出来。
注意：本地仓库本身也需要使用一个非中文、没有空格的目录。

2.1.4 配置阿里云提供的镜像仓库

修改Maven 的核心配置文件：conf/settings.xml，配置方式如下：
将原有的例子配置注释掉

<!-- <mirror>
  <id>maven-default-http-blocker</id>
  <mirrorOf>external:http:*</mirrorOf>
  <name>Pseudo repository to mirror external repositories initially using HTTP.</name>
  <url>http://0.0.0.0/</url>
  <blocked>true</blocked>
</mirror> -->

加入我们的配置

  <mirror>
    <id>nexus-aliyun</id>
    <mirrorOf>central</mirrorOf>
    <name>Nexus aliyun</name>
    <url>http://maven.aliyun.com/nexus/content/groups/public</url>
  </mirror>

2.1.5 配置 Maven 工程的基础 JDK 版本

修改Maven 的核心配置文件：conf/settings.xml，配置方式如下：

  <profile>
    <id>jdk-1.8</id>
    <activation>
    <activeByDefault>true</activeByDefault>
    <jdk>1.8</jdk>
    </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>

2.1.6 检查 JAVA_HOME 环境变量配置

参照 JAVA 学习笔记配置，不再赘述。

2.1.7 配置 MAVEN_HOME

在这里插入图片描述

2.1.8 配置 PATH

在这里插入图片描述

2.1.9 验证配置的结果

C:\Users\Administrator>mvn -v
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: D:\software\apache-maven-3.8.4
Java version: 1.8.0_141, vendor: Oracle Corporation, runtime: D:\software\Java\jre
Default locale: zh_CN, platform encoding: GBK
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

2.2 Maven 应用

2.2.1 Maven 坐标

在数学中使用 x、y、z 三个『向量』作为空间的坐标系，可以在『空间』中唯一的定位到一个『点』。
在这里插入图片描述
在 Maven 中，使用 groupId、artifactId、version 来确定唯一构件。

  • groupId：公司或组织域名的倒序，通常也会加上项目名称
    • 例如：com.atguigu.maven
  • artifactId：模块的名称，将来作为 Maven 工程的工程名
  • version：模块的版本号，根据自己的需要设定
    • 例如：SNAPSHOT 表示快照版本，正在迭代过程中，不稳定的版本
    • 例如：RELEASE 表示正式版本

举例：

  • groupId：com.atguigu.maven
  • artifactId：pro01-atguigu-maven
  • version：1.0-SNAPSHOT

坐标：

  <groupId>javax.servlet</groupId>
  <artifactId>servlet-api</artifactId>
  <version>2.5</version>

上面坐标对应的 jar 包在 Maven 本地仓库中的位置：

Maven本地仓库根目录\javax\servlet\servlet-api\2.5\servlet-api-2.5.jar

一定要学会根据坐标到本地仓库中找到对应的 jar 包。

2.2.2 Maven 在本地的三个目录

  • ★ Maven 核心程序：中军大帐
    在这里插入图片描述

  • ★ Maven 本地仓库：兵营
    在这里插入图片描述

  • ★ 本地工作空间：战场
    在这里插入图片描述

2.2.3 Maven 的相关命令

  • mvn archetype:generate
    Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 7:【直接回车，使用默认值】

Define value for property 'groupId': com.atguigu.maven

Define value for property 'artifactId': pro01-maven-java

Define value for property 'version' 1.0-SNAPSHOT: :【直接回车，使用默认值】

Define value for property 'package' com.atguigu.maven: :【直接回车，使用默认值】

Confirm properties configuration: groupId: com.atguigu.maven artifactId: pro01-maven-java version: 1.0-SNAPSHOT package: com.atguigu.maven Y: :【直接回车，表示确认。如果前面有输入错误，想要重新输入，则输入 N 再回车。】
  • mvn clean 效果：删除 target 目录
  • mvn compile 效果：主程序编译
    • 主体程序编译结果存放的目录：target/classes
  • mvn test-compile 效果：测试程序编译
    • 测试程序编译结果存放的目录：target/test-classes
  • mvn test
    • 测试的报告存放的目录：target/surefire-reports
  • mvn package
    • 打包的结果 - jar 包，存放的目录：target
    • 打包的结果 - war 包，存放的目录：target
  • mvn install
    • 安装的效果是将本地构建过程中生成的 jar、war 包存入 Maven 本地仓库。这个 jar、war 包在 Maven 仓库中的路径是根据它的坐标生成的。
  • mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.4
    • 参数 archetypeGroupId、archetypeArtifactId、archetypeVersion 用来指定现在使用的 maven-archetype-webapp 的坐标。

2.2.4 pom.xml 文件解读

文件解读
  <!-- 当前Maven工程的坐标 -->
  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro01-maven-java</artifactId>
  <version>1.0-SNAPSHOT</version>
  
  <!-- 当前Maven工程的打包方式，可选值有下面三种： -->
  <!-- jar：表示这个工程是一个Java工程  -->
  <!-- war：表示这个工程是一个Web工程 -->
  <!-- pom：表示这个工程是“管理其他工程”的工程 -->
  <packaging>jar</packaging>

  <name>pro01-maven-java</name>
  <url>http://maven.apache.org</url>

  <properties>
  <!-- 工程构建过程中读取源码时使用的字符集 -->
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <!-- 当前工程所依赖的jar包 -->
  <dependencies>
  <!-- 使用dependency配置一个具体的依赖 -->
    <dependency>
  
    <!-- 在dependency标签内使用具体的坐标依赖我们需要的一个jar包 -->
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
    
    <!-- scope标签配置依赖的范围 -->
      <scope>test</scope>
    </dependency>
  </dependencies>

<!-- 配置对Java工程pro01-maven-java的依赖 -->
<!-- 具体的配置方式：在dependency标签内使用坐标实现依赖 -->
<dependency>
  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro01-maven-java</artifactId>
  <version>1.0-SNAPSHOT</version>
</dependency>

依赖的范围

main目录（空间）test目录（空间）开发过程（时间）部署到服务器（时间）
compile有效有效有效有效
test无效有效有效无效
provided有效有效有效无效
依赖的传递性

在 A 依赖 B，B 依赖 C 的前提下，C 是否能够传递到 A，取决于 B 依赖 C 时使用的依赖范围。

  • B 依赖 C 时使用 compile 范围：可以传递
  • B 依赖 C 时使用 test 或 provided 范围：不能传递，所以需要这样的 jar 包时，就必须在需要的地方明确配置依赖才可以。
依赖的排除

当 A 依赖 B，B 依赖 C 而且 C 可以传递到 A 的时候，A 不想要 C，需要在 A 里面把 C 排除掉。而往往这种情况都是为了避免 jar 包之间的冲突。
在这里插入图片描述

<dependency>
  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro01-maven-java</artifactId>
  <version>1.0-SNAPSHOT</version>
  <scope>compile</scope>
  <!-- 使用excludes标签配置依赖的排除  -->
  <exclusions>
    <!-- 在exclude标签中配置一个具体的排除 -->
    <exclusion>
      <!-- 指定要排除的依赖的坐标（不需要写version） -->
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>
    </exclusion>
  </exclusions>
</dependency>
继承

Maven工程之间，A 工程继承 B 工程

  • B 工程：父工程
  • A 工程：子工程

本质上是 A 工程的 pom.xml 中的配置继承了 B 工程中 pom.xml 的配置。
在父工程中统一管理项目中的依赖信息，具体来说是管理依赖信息的版本。

它的背景是：

  • 对一个比较大型的项目进行了模块拆分。
  • 一个 project 下面，创建了很多个 module。
  • 每一个 module 都需要配置自己的依赖信息。

它背后的需求是：

  • 在每一个 module 中各自维护各自的依赖信息很容易发生出入，不易统一管理。
  • 使用同一个框架内的不同 jar 包，它们应该是同一个版本，所以整个项目中使用的框架版本需要统一。
  • 使用框架时所需要的 jar 包组合（或者说依赖信息组合）需要经过长期摸索和反复调试，最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。

通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的 jar 包；又能够将以往的经验沉淀下来，节约时间和精力。

  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro03-maven-parent</artifactId>
  <version>1.0-SNAPSHOT</version>

  <!-- 当前工程作为父工程，它要去管理子工程，所以打包方式必须是 pom -->
  <packaging>pom</packaging>

只有打包方式为 pom 的 Maven 工程能够管理其他 Maven 工程。打包方式为 pom 的 Maven 工程中不写业务代码，它是专门管理其他 Maven 工程的工程。

父工程的 pom.xml 被添加的内容：

<modules>  
  <module>pro04-maven-module</module>
  <module>pro05-maven-module</module>
  <module>pro06-maven-module</module>
</modules>

子工程的 pom.xml 被添加的内容：

<!-- 使用parent标签指定当前工程的父工程 -->
<parent>
  <!-- 父工程的坐标 -->
  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro03-maven-parent</artifactId>
  <version>1.0-SNAPSHOT</version>
</parent>

<!-- 子工程的坐标 -->
<!-- 如果子工程坐标中的groupId和version与父工程一致，那么可以省略 -->
<!-- <groupId>com.atguigu.maven</groupId> -->
<artifactId>pro04-maven-module</artifactId>
<!-- <version>1.0-SNAPSHOT</version> -->

在父工程中配置依赖的统一管理

<!-- 使用dependencyManagement标签配置对依赖的管理 -->
<!-- 被管理的依赖并没有真正被引入到工程 -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-core</artifactId>
      <version>4.0.0.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-beans</artifactId>
      <version>4.0.0.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-context</artifactId>
      <version>4.0.0.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-expression</artifactId>
      <version>4.0.0.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-aop</artifactId>
      <version>4.0.0.RELEASE</version>
    </dependency>
  </dependencies>
</dependencyManagement>

子工程中引用那些被父工程管理的依赖
关键点：省略版本号

<!-- 即使在父工程配置了对依赖的管理，子工程需要使用具体哪一个依赖还是要明确配置  -->
<!-- 子工程引用父工程中的依赖信息时，可以把版本号去掉。  -->
<!-- 把版本号去掉就表示子工程中这个依赖的版本由父工程决定。 -->
<!-- 具体来说是由父工程的dependencyManagement来决定。 -->
<!-- 子工程引用父工程中的依赖信息时，没有把版本号去掉 -->
<!-- 子工程版本号与父工程版本号一致，还是引用此版本 -->
<!-- 子工程版本号与父工程版本号不一致，子工程管理的版本会覆盖父工程管理的版本并最终采纳，绝大部分情况下子工程还是遵从父工程统一管理的依赖 -->
<dependencies>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-beans</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-expression</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-aop</artifactId>
  </dependency>
</dependencies>

在父工程中升级依赖信息的版本

      <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>4.1.4.RELEASE</version>
      </dependency>

然后在子工程中运行mvn dependency:list，效果如下：

[INFO] org.springframework:spring-aop:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-core:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-context:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-beans:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-expression:jar:4.1.4.RELEASE:compile

在父工程中声明自定义属性

<!-- 通过自定义属性，统一指定Spring的版本 -->
<properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  
  <!-- 自定义标签，维护Spring版本数据 -->
  <atguigu.spring.version>4.3.6.RELEASE</atguigu.spring.version>
</properties>

在需要的地方使用${}的形式来引用自定义的属性名：

      <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${atguigu.spring.version}</version>
      </dependency>

真正实现“一处修改，处处生效”。
在这里插入图片描述

2.2.5 约定的目录结构

java 项目
在这里插入图片描述
java web 项目
在这里插入图片描述

另外还有一个 target 目录专门存放构建操作输出的结果。

Maven 为了让构建过程能够尽可能自动化完成，所以必须约定目录结构的作用。例如：Maven 执行编译操作，必须先去 Java 源程序目录读取 Java 源代码，然后执行编译，最后把编译结果存放在 target 目录。
Maven 对于目录结构这个问题，没有采用配置的方式，而是基于约定。这样会让我们在开发过程中非常方便。如果每次创建 Maven 工程后，还需要针对各个目录的位置进行详细的配置，那肯定非常麻烦。
目前开发领域的技术发展趋势就是：约定大于配置，配置大于编码。

2.2.6 其他概念

1、生命周期
①作用
为了让构建过程自动化完成，Maven 设定了三个生命周期，生命周期中的每一个环节对应构建过程中的一个操作。

②三个生命周期

生命周期名称作用各个环节
Clean清理操作相关pre-clean
clean
post-clean
Site生成站点相关pre-site
site
post-site
deploy-site
Default主要构建过程validate
generate-sources
process-sources
generate-resources
process-resources 复制并处理资源文件，至目标目录，准备打包。
compile 编译项目 main 目录下的源代码。
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 复制并处理资源文件，至目标测试目录。
test-compile 编译测试源代码。
process-test-classes
test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
prepare-package
package 接受编译好的代码，打包成可发布的格式，如JAR。
pre-integration-test
integration-test
post-integration-test
verify
install将包安装至本地仓库，以让其它项目依赖。
deploy将最终的包复制到远程的仓库，以让其它开发人员共享；或者部署到服务器上运行（需借助插件，例如：cargo）。

③特点

  • 前面三个生命周期彼此是独立的。
  • 在任何一个生命周期内部，执行任何一个具体环节的操作，都是从本周期最初的位置开始执行，直到指定的地方。（本节记住这句话就行了，其他的都不需要记）

Maven 之所以这么设计其实就是为了提高构建过程的自动化程度：让使用者只关心最终要干的即可，过程中的各个环节是自动执行的。

2、插件和目标

①插件
Maven 的核心程序仅仅负责宏观调度，不做具体工作。具体工作都是由 Maven 插件完成的。例如：编译就是由 maven-compiler-plugin-3.1.jar 插件来执行的。

②目标
一个插件可以对应多个目标，而每一个目标都和生命周期中的某一个环节对应。
Default 生命周期中有 compile 和 test-compile 两个和编译相关的环节，这两个环节对应 compile 和 test-compile 两个目标，而这两个目标都是由 maven-compiler-plugin-3.1.jar 插件来执行的。

3、仓库

  • 本地仓库：在当前电脑上，为电脑上所有 Maven 工程服务
  • 远程仓库：需要联网
    • 局域网：我们自己搭建的 Maven 私服，例如使用 Nexus 技术。
    • Internet
      • 中央仓库
      • 镜像仓库：内容和中央仓库保持一致，但是能够分担中央仓库的负载，同时让用户能够就近访问提高下载速度，例如：Nexus aliyun

建议：不要中央仓库和阿里云镜像混用，否则 jar 包来源不纯，彼此冲突。
专门搜索 Maven 依赖信息的网站：https://mvnrepository.com/

UntifA
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
Maven相关知识
yk的博客
12-15 1949
Maven命令： mvn clean 清理项目生产的临时文件,一般是模块下的target目录 mvn compile 编译源代码，一般编译模块下的src/main/java目录 mvn package 项目打包工具,会在模块下的target目录生成jar或war等文件 mvn test 测试命令,或执行src/test/java/下junit的测试用例. mvn install 将打包的jar/war文件复制到你的本地仓库中,供其他模块使用 mvn deploy 将打包的文件发布到远程参考,提供..
Maven知识点
cmx1060220219的博客
01-25 319
Maven知识点 maven坐标 groupId：该元素定义了当前Maven项目隶属的实际项目，一般情况下该项元素都与公司域名相对应，比如com.taobao. artifactId：该元素定义了实际项目中的一个Maven Module version：该元素表示当前构件的版本，包括稳定（release）版本和测试（snapshot）版本 packaging：该元素定义Maven项目的打包方式，默认为jar，还有war和pom方式 war架包是 用于需要部署的web项目使用 pom的打包方式在父项目中使用，
Maven相关知识整理
一直在路上的小开发
03-02 539
MavenMaven基础Maven简介Maven基础概念依赖管理生命周期与插件Maven高级 Maven基础 Maven简介 Maven基础概念 依赖管理 生命周期与插件 Maven高级
maven 常用知识速记
a141210104的专栏
10-17 403
上例中的 JUnit 就是个很好的例子，该文件也以依赖的方式引入到测试使用的 classpath 中，不同的是这里的依赖范围是 test。例如，项目 A 有这样的依赖关系：A->B->C->X(1.0)、A->D->X(2.0),X 是 A 的传递性依赖，但是两条依赖路径上有两个版本的 X, 那么哪个 X 会被 Maven 解析使用呢？. 这种依赖意味着潜在的风险，当前项目直接在使用它们，例如有很多相关的 Java import 声明，而这种依赖是通过直接依赖传递进来的，该结果中重要的是两个部分。
Maven笔记.pdf
04-06
### Maven核心知识点解析 #### Maven概述与价值 Maven是一个项目管理和综合工具，主要用于Java项目的构建、依赖管理和项目信息管理。通过Maven，开发者可以轻松地处理项目中的多个痛点问题，提升开发效率。 #####...
idea离线导入maven项目
01-20
首先，你需要在有网络连接的计算机上下载所有必要的Maven依赖，并将它们复制到内网计算机的本地Maven仓库。默认情况下，Maven的本地仓库路径为`~/.m2/repository`（Windows系统下为`%USERPROFILE%\.m2\repository`...
maven 逆向逆向工程
06-21
通过分析类文件，Maven可以推断出必要的构建配置并填充到pom.xml中。 6. **命令行使用**：执行Maven逆向工程通常需要在命令行中使用特定的命令，例如`mvn archetype:create-from-project`。这个命令会根据当前项目...
maven3.3.9
03-18
** Maven 3.3.9 知识点详解 ** Maven 3.3.9 是 Apache Maven 的一个稳定版本，发布于2015年12月，它在Maven社区中广受好评，因其稳定性及可靠的性能而被开发者广泛应用。这个版本包含了对之前版本的诸多改进和修复...
springmvc maven工程
06-18
下面将详细探讨SpringMVC与Maven的结合使用及其相关知识点。 ### SpringMVC简介 SpringMVC是Spring框架的一部分，它为开发者提供了构建Web应用程序的灵活架构。主要特点包括： 1. **解耦**: 通过依赖注入（DI）和...
Maven(源码+lw+部署文档+讲解等)
lpw1012的博客
08-22 640
🌞博主介绍：✌全网粉丝15W+,CSDN特邀作者、211毕业、高级全栈开发程序员、大厂多年工作经验、码云/掘金/华为云/阿里云/InfoQ/StackOverflow/github等平台优质作者、专注于Java、小程序技术领域和毕业项目实战，以及程序定制化开发、全栈讲解、就业辅导✌🌞👇🏻精彩专栏 推荐订阅👇🏻2023-2024年最值得选的微信小程序毕业设计选题大全：100个热门选题推荐✅2023-2024年最值得选的Java毕业设计选题大全：500个热门选题推荐✅Java精品实战案例《500套》
Maven3.5.3下载安装与环境配置
caoyanchao1的博客
08-19 344
由于Maven官网更新，导致之前参考的方法不能使用，特在此基础上进行更新。】时，发现下载界面是最新版本的Maven，这时候滚动条往下拉，找到【配置阿里云setting.xml文件内容补充。分开写,否则出现以下错误。其他发布版本，点击【
Maven 管理依赖的详细步骤
weixin_42564451的博客
08-22 630
良好的依赖管理实践可以显著提高项目的可维护性和稳定性。
maven快速清除lastUpdated文件
qq_47910339的博客
08-22 140
项目使用maven管理jar包，很容易因为各种原因(网速慢、断网)导致jar包下载不下来，出现很多.lastUpdated文件。这些文件一个一个删除太麻烦。下面是全部删除的方法
Maven-02.介绍&安装
程小白的博客
08-19 332
【代码】Maven-02.介绍&安装。
寄快递小程序（源码）.zip
最新发布
08-22
寄快递小程序（源码）.zip
基于Springboot的 个人博客系统的设计与实现源码 （优秀毕业设计源码）
08-22
1. 个人博客系统的设计与实现代码说明：经导师指导并认可通过的98分毕设项目代码。 2.适用对象：本代码学习资料适用于计算机、电子信息工程、数学等专业正在做毕设的学生，需要项目实战练习的学习者，也适用于课程设计、期末大作业。 3.技术栈：前端是vue，后端是springboot，项目代码都经过严格调试，代码没有任何bug！ 4. 作者介绍：大厂码农，java领域创作者，阿里云开发社区乘风者计划专家博主，专注于大学生项目实战开发，文章底部有博主联系方式，更多优质系统、项目定制请私信。 5. 最新计算机软件毕业设计选题大全: https://blog.csdn.net/weixin_45630258/article/details/135901374
数学建模-2021年-国赛D题-解决连铸切割问题（模拟训练专用）
08-22
题是在参加学校数学建模培训时的第二道模拟训练题，为2021年国赛D题解决连铸切割问题。该题主要采用多目标规划以及序贯解法解决。本题的最终论文已存放在该压缩包感兴趣可下载使用学习。本文针对尾坯长度和结晶器异常情况，给出最优的切割方案，满足用户的目标要求和正常要求。 解决这个问题可以提高生产效率，减少资源浪费，满足用户需求，确保生产线的正常运行。 问题一：这个问题根据尾坯长度制定出最优的切割方案，这是一个规划优化类问题。我们使用了多目标规划模型和序贯算法，首先考虑报废钢坯的长度，使报废钢坯长度最小；其次考虑用户要求，在相同的切割损失下，切割出的钢坯尽量满足用户的目标范围中的目标值，得出最优切方案（表 1）。 问题二： 在钢坯第 1 次出现报废段时，给出此段钢坯的切割方案； 我们继续使用多目标规划模型，目标一：首先考虑报废钢坯的长度，使报废钢坯长度最小； 目标二： 其次考虑用户要求，在相同的切割损失下，切割出的钢坯尽量满足用户的目标范围[9.0,10.0]标;目标三：达到用户目标值 9.5m。 根据多目标规划模型分别依次计算从初始时刻到每次结晶器异常时刻的尾坯切割方案
1021330100000000606020231723102386644
08-22
1021330100000000606020231723102386644
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值