> 文章列表 > Maven笔记2

Maven笔记2

Maven笔记2

Maven笔记

  1. maven在idea中有四个快速管理工具

    1. Lifecycle:翻译为“生命周期”,开发一个项目包括以下几种生命周期:
      • clean:清理项目输出的target文件夹
      • validate:验证项目是否正确且所有必须信息是否可用
      • compile:编译源代码编译在此阶段完成
      • test:测试,使用适当的单元测试框架运行测试
      • package:打包,创建JAR/WAR包如在 pom.xml 中定义的包
      • verify:检查,对集成测试的结果进行检查,以保证质量达标
      • install:安装,安装打包的项目到本地仓库,以供其他项目使用
      • deploy:部署,拷贝最终的工程包到远程仓库中,以共享给其他开发人员和工程
    2. Plugins:插件
      • 在pom.xml文件中配置的项目所需要的插件,添加的插件都在Plugins目录下。
      • Lifecycle是项目的生命周期,每个生命周期都有与之对应的插件来完成生命周期该完成的工作。在idea中与生命周期对应的插件就是显示在Plugins当中的。
      • 每个生命周期执行到某个插件是有约定的。我们可以配置插件绑定到项目构建的生命周期中。
    3. Dependencies:依赖
      • 依赖在idea中的显示格式是基于坐标的(组织Id:项目Id:版本号)
      • 例如:[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jNNG6gjZ-1682074052897)(C:\\Users\\XueYingHao\\AppData\\Roaming\\Typora\\typora-user-images\\image-20230421130805904.png)]后面"(test)"代表这个依赖的作用域时test文件夹【也可以说时这里的值】。
        • junit:junit:4.12
          • 组织id:junit
          • 项目id:junit
          • 版本号:4.12
        • junit:junit:4.12下面还有一个依赖(org.hamcrest:hamcrest-core:1.3),说明junit这个项目用到了(org.hamcrest:hamcrest-core:1.3)依赖
          • 组织id:org.hamcrest
          • 项目id:hamcrest-core
          • 版本号:1.3
    4. Run Configurations
      • 这个里都是我们在【Run/Debug Configurations】里配置的东西。
  2. 使用模板/原型创建Maven工程【archetype译为原型】

    • 创建普通java工程,选择
      • org.apache.maven.archetypes:maven-archetype-quickstart.
    • 创建web项目使用的模板:
      • org.apache.cocoon:cocoon-22-archetype-webapp
  3. 一个Java项目只能有一个Java源代码的根目录,在idea中怎么设置?

    • 在项目结构中:进行设置,点击左边的modules,各个标记的意思
      1. Sources:Java项目源代码的存放位置,用“蓝色”文件夹表示
      2. Tests:Java项目的测试程序存放的位置,用“绿色”文件夹表示
      3. Resources:java源文件的配置文件存放位置
      4. Test Resources:Java测试程序的配置文件的存放位置
      5. Excluded:项目输出的位置
  4. version:

    • RELEASE代表完成版
    • SNAPSHOT代表开发版
  5. pom.xml常用标签

    1. <!--以下三个标签用来定义项目的坐标-->
      <groupId>com.xyh</groupId>  <!--组织id-->
      <artifactId>mvn-test01</artifactId> <!--项目id-->
      <version>1.0-SNAPSHOT</version><!--项目的版本号-->
      
    2. <packaging>war</packaging><!--项目的打包方式,默认是jar包,web工程就打成war包-->
      <!--打包方式如果选择war包的话需要添加一个插件帮助我们打包,添加插件的时候必须写在build标签中-->
      <build><!--所有的插件都要写在这个标签中--><plugins><!--代表一个插件--><plugin><!--这是插件在仓库中的坐标,maven的插件是用Java写出来的所以,插件一般都是以jar包的形式存在的--><groupId>org.apache.maven.plugins</groupId><artifactId>maven-war-plugin</artifactId><version>3.2.0</version></plugin></plugins>
      </build>
      
    3. <!--导入依赖-->
      <!--dependencies标签中是整个项目中所有的依赖-->
      <dependencies><!--dependency表示一个固定的依赖--><dependency><!--依赖的第三方类库的坐标,引入依赖--><!--如果前后引入了两个相同的依赖库,那么后面的会覆盖前面的,后面的生效--><groupId>junit</groupId><artifactId>junit</artifactId><version>4.12</version><scope>test</scope></dependency>
      </dependencies>
      
  6. 运行第一个web项目

    1. 运行web项目的时候需要使用web服务器,web服务器就是用Tomcat服务器,所以需要在项目中添加Tomcat插件或者直接将项目部署在本地的Tomcat服务器中,在这里选择在项目中添加Tomcat插件。

    2. 添加Tomcat插件首先需要找到插件在仓库中的坐标,在mvnrepository.com中搜索“tomcat maven”,找到坐标之后,将坐标添加到插件。

      <build><plugins><plugin><!--插件的坐标--><groupId>org.apache.tomcat.maven</groupId><artifactId>tomcat7-maven-plugin</artifactId><version>2.1</version><!--设置插件的配置信息,因为当前的插件是Tomcat插件,所以就是设置Tomcat插件的配置信息--><configuration><!--设置Tomcat服务器的端口号为,不设置默认也是8080--><port>80</port><!--服务器上可以部署很多个应用,path用于设置当前应用的根路径,如果是“/”代表当前应用的根路径就是服务器的根路径--><path>/</path></configuration></plugin></plugins></build>
      
    3. 刷新maven此时会出现tomcat7的插件,点开插件双击“tomcat7:run”就可以运行起来。

依赖管理

  1. 依赖配置是当前项目所需要使用的jar包通过“依赖配置”这种方式传递给当前项目。

    • 依赖是指:当前项目运行所需要的jar,一个项目中可以设置多个依赖。

    • 我们可以依赖被人写好的项目,别人也可以使用我们写好的jar(项目打包生成的jar)。

    • jar包就是一堆class字节码文件。

    • <!--maven导入依赖的格式,在pom.xml文件的根标签下直接写-->
      <dependencies><!--只要是一个Maven项目就肯定有项目的坐标,这里甚至可以写自己的坐标,自己依赖自己,虽然这么些没有意义,但是可以这么写--><dependency><groupId>组织Id</groupId><artifactId>项目Id</artifactId><version>版本号</version><!--表示这个依赖只能用于test文件夹下--><scope>test</scope></dependency>......<!--在这里可以配置多个依赖-->
      </dependencies>
      
  2. 依赖传递

    1. 什么是依赖传递?

      1. pom.xml中引入的依赖,在构建或者运行的时所有必要的类和资源都会自动添加到项目的classpath中。
      2. Maven 中的依赖是有传递性的,默认会包含传递的依赖,这样就不用手动引用每一个依赖了。
      3. 加入B项目依赖A项目,A项目用到了junit依赖,B项目使用到了A项目,通过pom.xml依赖配置将A的项目引入B项目中之后,B项目中也存在A的这个项目中的junit依赖,这就是依赖的传递。
    2. 因为依赖具有传递性,所以又分为直接依赖个间接依赖:直接依赖和间接依赖是相对的概念,某个依赖相对于A模块可能是直接依赖,但是相对于B模块可能是间接依赖

      1. 直接依赖:在当前项目中通过依赖配置建立的依赖关系
      2. 间接依赖:通过依赖传递传递过来的依赖,我们在项目中可以直接使用的,我们称为间接依赖。【也可以说是:直接依赖的依赖】,直接依赖的依赖传递给我们的项目中的依赖叫做间接依赖。
    3. 依赖传递中的冲突问题?

      1. 路径优先:当依赖中出现了相同的资源时,层级越深,优先级越低,层级越浅,优先级越高。
      2. 声明优先:当资源在相同层级被依赖时,配置顺序靠前的覆盖配置顺序靠后的资源。
      3. 特殊优先:当在pom.xml文件中配置了多个相同的依赖(多个标签),可以是不同版本的依赖,后配置的覆盖先配置的。
    4. 怎样看层级关系?

      • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4TuvFy3r-1682074052899)(C:\\Users\\XueYingHao\\AppData\\Roaming\\Typora\\typora-user-images\\image-20230421152838413.png)]
      • 上图目录中往后越“缩进”就代表层级越深,层级越深,优先级越低。
    5. 可选依赖:假设B项目依赖A项目,A项目中使用的依赖,不传递给B项目,B项目不知道A项目用到了那些依赖?【叫做隐藏自己使用的依赖】

      1. 可选依赖:可选依赖指对外隐藏当前所依赖的资源。

        <dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.13.2</version><!--在项目中加上这个标签代表代表当前项目的当前依赖不传递给下一个项目不加,该标签的默认值时false--><optional>true</optional>
        </dependency>
        
    6. 排除依赖:指主动断开依赖的资源,排除依赖无需指定版本。

      1. <dependency><!--这是引入的依赖“mvn-test03”--><groupId>com.xyh</groupId><artifactId>mvn-test03</artifactId><version>1.0-SNAPSHOT</version><exclusions><!--如果“mvn-test03”依赖中存在junit传递依赖,那么当前项目自动屏蔽junit依赖--><exclusion><!--这是写排除的坐标,不需要写版本号,因为一排除就是所有的依赖--><groupId>junit</groupId><artifactId>junit</artifactId></exclusion>....<!--可以排除多个传递依赖--></exclusions>
        </dependency>
        
    7. 总结:

      1. 可选依赖:上面不给了
      2. 排除依赖:下面不要了
  3. 在这个开源的时代里,几乎任何java应用都会借用一些第三方的开源类库,这些类库都可以通过依赖的方式引入到项目中。

  4. 依赖管理:依赖范围

    1. 依赖的jar默认情况下在任何地方都可以使用,可以通过scope标签设定其作用范围。

    2. 作用范围:

      1. 主程序范围有效(main文件夹范围内)
      2. 测试程序范围有效(test文件夹范围有效)
      3. 是否参与打包 (package指令范围内)
    3. scope 主程序(main) 测试代码(test) 打包 范例
      compile(默认) Y Y Y log4j
      test Y junit
      provided Y Y servlet-api
      runtime Y jdbc
    4. maven的scope有哪些[只是常用的这四种]:

      1. compile:compile是默认值,当我们引入依赖时,如果没有scope标签指定作用范围,那么默认就是compile。compile表示被依赖项目需要参与当前项目的编译,包括后续的测试,运行周期也参与其中,同时打包的时候也会包含进去。是最常用的,所以也是默认的。
      2. runtime:runtime表示被依赖项目无需参与项目的编译,不过后期的测试和运行周期需要其参与。与compile相比,跳过编译而已。
      3. test:test表示只会在测试阶段使用,在src/main/java里面的代码是无法使用这些api的,并且项目打包时,也不会将"test"标记的打入"jar"包或者"war"包。
      4. provided:provided表示的是在编译和测试的时候有效,在执行(mvn package)进行打包成war、jar包的时候不会加入,比如:servlet-api,因为servlet-api,tomcat等web服务器中已经存在,如果在打包进去,那么包之间就会冲突.

生命周期与插件

构建生命周期

  1. Maven对项目构建的生命周期划分为3套
    1. clean:清理工作。
      1. pre-clean:执行一些需要在clean之前完成的工作
      2. clean:移除所有上一次构建生成的文件
      3. post-clean:执行一些需要在clean之后完成的工作
        • 要执行post-clean阶段,前提是“pre-clean”和“clean”阶段都已经完成了。
    2. default:核心工作,例如:编译,测试,打包,部署等。
    3. site:产生报告,发布站点。

插件

  1. 插件概述
    1. 插件与生命周期内的阶段绑定,在执行到对应的生命周期执行对应的插件功能
    2. 默认Maven在各个生命周期上绑定有预设的功能(这些预设的功能由指定的插件完成)
    3. 通过插件可以自定义其他功能(Maven具有的功能都是插件完成的)
  2. 生命周期指的是运行的阶段,插件是为了支持生命周期的那些工作。【生命周期可以理解为是几岁,插件理解为是几岁干的那件事】

e:产生报告,发布站点。

插件

  1. 插件概述
    1. 插件与生命周期内的阶段绑定,在执行到对应的生命周期执行对应的插件功能
    2. 默认Maven在各个生命周期上绑定有预设的功能(这些预设的功能由指定的插件完成)
    3. 通过插件可以自定义其他功能(Maven具有的功能都是插件完成的)
  2. 生命周期指的是运行的阶段,插件是为了支持生命周期的那些工作。【生命周期可以理解为是几岁,插件理解为是几岁干的那件事】