Maven学习笔记（十）坐标与依赖

最新推荐文章于 2023-04-27 15:03:52 发布
最新推荐文章于 2023-04-27 15:03:52 发布
阅读量1.1k 收藏
点赞数
分类专栏： Maven 文章标签： maven 依赖
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xvjianzhe/article/details/43721389
版权

坐标与依赖

    Maven的一大功能是管理项目依赖，为了能自动化解析任何一个java构件，Maven就必须将它们唯一标识，这就依赖管理的底层基础——坐标！
何为Maven坐标
    Maven定义了这样一组规则：世界上任何一个构件都可以使用Maven坐标唯一标识，Maven坐标的元素包括groupId，artifactId，version，packing，classifier。只要提供正确的Maven坐标，Maven就能找到对应的构件。

    比如说，需要使用Java5平台上TestNG的5.8版本时，就可以告诉Maven：“groupId=org.testng;artifactId=testng;version=5.8;classifier=jdk15”，Maven就会从仓库中寻找对应的构件来供我们使用。

    Maven坐标为各种构建引入了秩序，任何一个构件都必须明确定义自己的坐标，而一组Maven坐标是通过一些元素定义的，如下所示：

<groupId>junit</groupId>
        <artifactId>junit</artifactId>
     <version>4.7</version>
<packaging>jar</ packaging>
    这是Junit的坐标定义，下面解释下各个元素的定义:

           groupId：定义当前Maven隶属的实际项目。首先Maven项目和实际项目不一定是一对一关系。比如SpringFramework这一实际项目，它对应的Maven项目会有很多，比如spring-core，spring-context等。这是由于Maven中模块的概念，因此一个实际项目往往会被分为很多模块。其次，groupId不应该对应项目隶属的组织或公司，因为一个组织下可能会有多个实际项目，如果groupId只定义到组织级别，而后面我们会看到artifactId只能定义Maven项目（模块），那么实际项目这个层将难以定义。最后groupId的表示方式与Java包名的表示方式类似，通常与域名反向一一对应。

           artifactId：该元素定义实际项目中的一个Maven项目（模块），推荐的做法是使用实际项目名称作为artifactId的前缀。默认情况下，Maven生成的构件，其文件名会以artifactId作为开头。

           version：该元素定义Maven项目当前所处的版本。Maven定义了一套完整的版本规范，以及快照（SNAPSHOT）的概念。

           packaging：钙元素定义Maven项目的打包方式。首先打包方式通常与所生成构件的文件扩展名对应。其次，打包方式会影响到构建的生命周期，比如jar打包和war打包会使用不同的命令。最后当不定义packaging的时候，默认的打包方式为jar。

           classifier：钙元素用来帮助定义构建输出的一些附属构件。注意：不能直接定义classifier，因为附属构件不是由项目直接生成的，而是由附加的插件帮助生成。

    上述部分，groupId，artifactId，version三个元素是必须定义的，这也是Maven定义构件的三个重要元素，类似于3D空间的X,Y,Z坐标。packaging是可选的，classifier是不能直接定义的。
account-email
    在弄清楚Maven坐标的定义后，来看下AccountService项目下，account-email模块的pom.xml文件的内容：

<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.my.account</groupId>
  <artifactId>account-email</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>account-email</name>
  <url>http://maven.apache.org</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies> 
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.7</version>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>com.my.account</groupId>
      <artifactId>account-common</artifactId>
      <version>1.0.0-SNAPSHOT</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>2.5.6</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>2.5.6</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>2.5.6</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context-support</artifactId>
        <version>2.5.6</version>
    </dependency>
    <dependency>
        <groupId>javax.mail</groupId>
        <artifactId>mail</artifactId>
        <version>1.4.1</version>
    </dependency>
    <dependency>
        <groupId>com.icegreen</groupId>
        <artifactId>greenmail</artifactId>
        <version>1.3.1b</version>
        <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.5</source>
                <target>1.5</target>
            </configuration>
        </plugin>
    </plugins>
  </build>
</project>
    因为该模块属于账户注册服务项目的一部分，因此其groupId对应了account项目。接着，该模块的artifactId仍然以account作为前缀，以方便区分其他项目的构建。最后1.0.0-SNAPSHOT表示该版本处于开发状态，还不稳定。

    再看dependencies元素，其包含了多个dependency子元素，这是POM文件中定义项目依赖的位置。以Junit为例，它定义的内容为：

<dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.7</version>
      <scope>test</scope>
</dependency>
    这些便是依赖的坐标，任何一个Maven项目都需要定义自己的坐标，当这个Maven项目成为其他Maven项目的依赖的时候，这组坐标就体现了其价值。这个依赖的特殊地方在于，它定义了scope子元素，scope用来定义依赖范围，因为是Junit因此这个定义为test，表示只有在测试的时候才需要，也就是说对于项目主代码，该依赖是没有任何作用的。

    最后，POM中有一段关于maven-compiler-plugin的配置，其目的是开启java 5的支持。
account-email的主代码
    account-email项目java主代码位于src\main\java，资源文件位于src\main\resources目录下。

    account-email只有一个简单的接口，如下所示：

package com.my.account.account_email;

import com.my.account.account_common.exception.AccountEmailException;

public interface AccountEmailService {
        void sendMain(String to,String subject,String htmlText) throws AccountEmailException;
}


对于接口的实现代码如下：
package com.my.account.account_email.business;

import javax.mail.MessagingException;
import javax.mail.internet.MimeMessage;

import org.springframework.mail.javamail.JavaMailSender;
import org.springframework.mail.javamail.MimeMessageHelper;

import com.my.account.account_common.exception.AccountEmailException;
import com.my.account.account_email.AccountEmailService;

public class AccountEmailServiceImpl implements AccountEmailService {

    private JavaMailSender javaMailSender;

    private String systemEmail;

    public void sendMain(String to, String subject, String htmlText)
            throws AccountEmailException {
        MimeMessage msg = javaMailSender.createMimeMessage();

        MimeMessageHelper messageHelper = new MimeMessageHelper(msg);

        try {
            messageHelper.setFrom(systemEmail);
            messageHelper.setTo(to);
            messageHelper.setSubject(subject);
            // true 表示邮件内容为html格式
            messageHelper.setText(htmlText, true);

            javaMailSender.send(msg);
        } catch (MessagingException e) {
            e.printStackTrace();
            throw new AccountEmailException("发送邮件失败", e);
        }
    }

    public void setJavaMailSender(JavaMailSender javaMailSender) {
        this.javaMailSender = javaMailSender;
    }

    public void setSystemEmail(String systemEmail) {
        this.systemEmail = systemEmail;
    }

}
    对于字段javaMailSender的注入，使用Spring的IOC机制进行。

    代码中并没有邮件服务器配置信息，这主要是依靠SpringFramework的依赖注入，这些配置都通过外部的配置注入到了javaMailSender中，配置如下：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
    <!-- Spring中用来帮助载入properties文件的组件 -->
    <bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <!-- 表示从本地classpath的根路径下加载email.properties文件 -->
        <property name="location" value="classpath:email.properties" />
    </bean>
    <bean id="javaMailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
        <property name="protocol" value="${email.protocol}" />
        <property name="host" value="${email.host}" />
        <property name="port" value="${email.port}" />
        <property name="username" value="${email.username}" />
        <property name="password" value="${email.password}" />
        <property name="javaMailProperties" >
            <props>
                <prop key="mail.${email.protocol}.auth">${email.auth}</prop>
            </props>
        </property>
    </bean>
    <bean id="accountEmailService" class="com.my.account.account_email.business.AccountEmailServiceImpl">
        <property name="javaMailSender" ref="javaMailSender" />
        <property name="systemEmail" value="${email.systemEmail}"></property>
    </bean>

</beans>
    至于邮件的配置信息，由properties文件定义如下：

email.protocol=smtp
email.host=localhost
email.port=25
email.username=test@xv.com
email.password=123456
email.auth=true
email.systemEmail = test@xv.com
account-emaill的测试代码
    测试相关的java代码位于src\test\java目录，相关的资源文件在src\test\resource目录下。

    测试代码如下：

package com.my.account.account_email;

import static org.junit.Assert.assertEquals;

import javax.mail.Message;
import javax.mail.MessagingException;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

import com.icegreen.greenmail.util.GreenMail;
import com.icegreen.greenmail.util.GreenMailUtil;
import com.icegreen.greenmail.util.ServerSetup;
import com.my.account.account_common.exception.AccountEmailException;

public class AccountEmailServiceImplTest {

    private GreenMail greenmail;

    @Before
    public void startMailServer() {
        greenmail = new GreenMail(ServerSetup.SMTP);
        greenmail.setUser("test@xv.com", "123456");
        greenmail.start();
    }

    @Test
    public void testSendMail() throws AccountEmailException,
            InterruptedException, MessagingException {
        ApplicationContext ctx = new ClassPathXmlApplicationContext(
                "account-email.xml");
        AccountEmailService accountEmailService = (AccountEmailService) ctx
                .getBean("accountEmailService");
        String subject = "Test Subject";
        String htmlText = "<h3>Test</h3>";

        accountEmailService.sendMain("test2@xv.com", subject, htmlText);

        greenmail.waitForIncomingEmail(2000, 1);

        Message[] messages = greenmail.getReceivedMessages();
        assertEquals(1, messages.length);
        assertEquals(subject, messages[0].getSubject());
        assertEquals(htmlText, GreenMailUtil.getBody(messages[0]).trim());

    }

    @After
    public void stopMailServer(){
        greenmail.stop();
    }
}
构建account-email
    接下来可以使用命令：

        mvn clean test
    执行测试，Maven会编译主代码和测试代码，并执行测试。

    使用如下命令，将项目生成的构件account-email-1.0.0-SNAPSHOT.jar安装到本地仓库中。

        mvn clean install
依赖配置
    一个依赖声明可以包含如下一些元素：

<project>
  <dependencies>
    <dependency>
      <groupId>…</groupId>
      <artifactId>….</artifactId>
      <version>….</version>
      <type>….</type>
      <scope>….</scope>
      <optional></optional>
      <exclusions>
        <exclusion></exclusion>
      </exclusions>
    </dependency>
  </dependencies>
</project>
    根元素project下的dependencies可以包含一个或者多个dependency元素，以声明一个或者多个项目依赖，每个项目依赖可以包含的元素有：

           groupId，artifactId和version：依赖的基本坐标。对于任何一个依赖来说基本坐标都是最重要的，Maven根据坐标才能找到需要的依赖。

           type：依赖的类型，对应项目坐标定义的packaging，其默认值为jar

           scope：依赖的范围

           optional：标记依赖是否可选。

           exclusions：用来排除传递性依赖。
依赖范围
    首先，我们要了解，Maven在编译项目主代码的时候需要使用一套classpath。其次，Maven在编译和执行测试的时候会使用另外一套claspath。最后实际运行Maven项目的时候又会使用一套classpath。

    依赖范围就是用来控制依赖与这三种classpath的关系。Maven有以下几种依赖范围：

           compile：编译依赖范围，如果没有指定，默认就使用该依赖范围。这种依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效。

           test：测试依赖范围。使用此依赖范围的Maven依赖，只对于测试classpath有效。在编译主代码或者运行项目的使用时，将无法使用此类依赖。

           provided：已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效。例如servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍。

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

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

<dependency>
      <groupId>…</groupId>
      <artifactId>… </artifactId>
      <version>…</version>
      <scope>system</scope>
      <systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
         import：导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。该依赖范围主要与dependencyManagement元素配合使用。

    依赖范围与classpath的关系

这里写图片描述

传递性依赖
    什么是传递性依赖？

    打个简单的比方，有项目A，如果不使用Maven，那么项目A就需要下载它所依赖的B类库，而B类库又依赖C类库，因此在工作中我们往往会下载一个非常大的包来解决这个问题。

    Maven的传递性依赖机制可以非常好的解决这一个问题。

    以account-email为例，该项目有一个org.springframework:spring-core:2.5.6的依赖，实际上spring-core也有它自己的依赖，我们可以直接访问位于中央仓库的该构件的POM，可以看到该文件包含了一个commons-logging依赖，该依赖没有声明依赖范围，那么其依赖范围就是默认的compile。同时account-email的spring-core的依赖范围也是compile。

    account-mail有一个compile范围的spring-core依赖，spring-core有一个compile范围的commons-logging依赖，那么commons-logging就会成为account-email的compile范围的依赖，commons-logging是account-eamil的一个传递性依赖，如下图所示：

这里写图片描述

    Maven会解析各个直接依赖的POM，将那些必要的间接依赖，以传递性依赖的形式引入到当前的项目中。
传递性依赖和依赖范围
    依赖范围不仅可以控制依赖与三种classpa的关系，还对传递性依赖产生影响。

    假设A依赖于B，B依赖于C，我们说A对于B是第一直接依赖，B对于C就是第二直接依赖，A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围。如下图所示，最左边一列表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间的交叉单元格则表示传递性依赖范围：

这里写图片描述

    根据上表，可以发现这样的规律：

    当第二直接依赖范围是compile的时候，传递性依赖范围与第一直接依赖范围一致。当第二直接依赖范围是test的时候，依赖不会得以传递，当第二直接依赖范围是provided的时候，只传递第一直接依赖范围也为provided的依赖，且传递性依赖范围同样为provided；当第二直接依赖的范围是runtime的时候，传递性依赖范围与第一直接依赖范围一致，但compile例外，此时依赖范围为runtime。
依赖调解
    假如项目A有这样的依赖关系：A>B>C>X(1.0)、A>D>X(2.0)，X是A的传递性依赖，但是两条依赖路径上有两个版本的X，那么哪个X会被解析呢？这个时候Maven的依赖调解机制就发生了作用，Maven依赖调解的第一原则是：路径近者优先。因此最后使用的是2.0版本的X。

    但是有些时候依赖调解的第一原则不能解决所有问题，比如这样的依赖关系：A>B>Y(1.0)、A>C>Y(2.0)，路径长度一样，那么会使用哪个版本的Y呢？Maven定义了依赖调解的第二原则：第一声明者优先， 也就是说会使用1.0版本的Y。

    在路径长度相等的情况下，在POM中依赖声明的顺序决定了谁会被解析调用，顺序最靠前的那个依赖优胜。
可选依赖
    假设有这样一个依赖关系，A>B>X and Y ，B对于X和Y的依赖都是可选依赖：A>B，B>X（可选），B>Y（可选）。根据传递性依赖的定义，如果所有这三个依赖的范围都是compile，那么X，Y就是A的compile范围传递性依赖。然而，这里由于X、Y都是可选依赖，依赖将不会得以传递。如下图所示：

这里写图片描述

    那为什么会有可选依赖这一个特性呢？可能项目B实现了两个特性，其中特性A依赖与X，特性B依赖与Y，而且这两个特性是互斥的，用户不可能同时使用两个特性，比如持久层的隔离包，它支持多种数据库，如果在构建这个工具包的时候，需要这两种数据库的驱动程序，但在使用这个工具包的时候，只会依赖一种数据库。

    项目B的依赖声明如下：

<dependencies>
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>5.1.10</version>
      <optional>true</optional>
    </dependency>
    <dependency>
      <groupId>postgresql</groupId>
      <artifactId>postgresql</artifactId>
      <version>8.4-701.jdbc3</version>
      <optional>true</optional>
    </dependency>
  </dependencies>
    使用optional元素表示mysql-connector-java和postgresql这两个依赖为可选依赖，它们只会对当前项目B产生影响，当其他项目依赖于B的时候，这两个依赖不会被传递。

    当项目A依赖于项目B的时候，如果实际使用基于Mysql数据库，那么在项目A中就需要显示地声明mysql-connector-java这一依赖。如下所示：

<dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>5.1.10</version>
 </dependency>
    在理想的情况下，是不应该使用可选依赖的，在面向对象设计中，有个单一职责性原则，意指一个类应该只有一项职责，而不是糅合太多的功能。在上面的例子中，比较好的做法是为Mysql和PostgreSQL分别创建一个Maven项目，基于同样的groupId分配不同的artifactId，在各自POM中声明对应的JDBC驱动依赖，而且不使用可选依赖，用户根据需要选择其中之一使用，由于传递性依赖的作用，就不用再声明JDBC驱动依赖。
排除依赖
    传递性依赖会给项目隐式的引入很多依赖，这简化了项目依赖的管理，但是也会带来一些问题。比如当前项目有一个第三方依赖，而这个第三方依赖由于某些原因依赖了另外一个类库的SNAPSHOT版本，那么这个SNAPSHOT就会成为当前项目的传递性依赖，而SNAPSHOT的不稳定性会直接影响到当前项目，这时候就要排除掉SNAPSHOT，并且在当前项目中声明该类库的某个正式发布的版本。

    代码如下所示：

<dependency>
      <groupId>com.my.account</groupId>
      <artifactId>account-common</artifactId>
      <version>1.0.0-SNAPSHOT</version>
      <exclusions>
        <exclusion>
            <groupId>com.my.account</groupId>
            <groupId>project-c</groupId>
        </exclusion>
      </exclusions>
    </dependency>
    <dependency>
        <groupId>com.my.account</groupId>
        <artifactId>project-c</artifactId>
        <version>1.0.0</version>
</dependency>
    代码中使用exclusions元素声明排除依赖，exclusions可以包含一个或多个exclusion元素，因此可以排除一个或者多个传递性依赖。需要注意的是，声明exclusion只需要groupId和artifactId，而不需要versin元素，这是因为只要groupId和artifactId就能唯一定位依赖图中的某个依赖，换句话说就是Maven解析后的依赖中，不可能出现groupId和artifact乡土但是version不同的两个依赖，该例的依赖逻辑图如下所示：

这里写图片描述

归类依赖
    先看代码如下：

<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.my.account</groupId>
  <artifactId>account-email</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>account-email</name>
  <url>http://maven.apache.org</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies> 
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.7</version>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>com.my.account</groupId>
      <artifactId>account-common</artifactId>
      <version>1.0.0-SNAPSHOT</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>2.5.6</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>2.5.6</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>2.5.6</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context-support</artifactId>
        <version>2.5.6</version>
    </dependency>
    <dependency>
        <groupId>javax.mail</groupId>
        <artifactId>mail</artifactId>
        <version>1.4.1</version>
    </dependency>
    <dependency>
        <groupId>com.icegreen</groupId>
        <artifactId>greenmail</artifactId>
        <version>1.3.1b</version>
        <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.5</source>
                <target>1.5</target>
            </configuration>
        </plugin>
    </plugins>
  </build>
</project>
    可以看到在上面的代码中有很多springframework的依赖，它们是来自同一项目的不同模块，因此这些依赖的版本都是相同的，如果将来需要升级springframework，这些依赖的版本都会一起升级。这一种情况在java代码中似曾相识，看下下面的代码：

public double c(double r){
        return 2*3.14*r;
}

public double s(double r){
        return 3.14*r*r;
}
    上面两个方法一个计算周长一个计算面积，一般来说，我们通常会将字面量定义成一个常量，这样在以后的修改的时候能够做到修改一处即可，如下代码：

public final double PI = 3.14;

public double c(double r){
        return 2*PI*r;
}

public double s(double r){
        return PI*r*r;
}
    使用常量不仅让代码变得简洁，更重要的是可以避免重复，在需要更改PI的值的时候，只需要更改一处，降低了错误发生的概率。

    同理对于POM文件来说，我们也可以在一个唯一的地方定义版本，并且在dependency声明中引用这一版本。这样在springframework升级的时候只需要修改一处即可，如下所示：

<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.my.account</groupId>
  <artifactId>account-email</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>account-email</name>
  <url>http://maven.apache.org</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <springframework.version>2.5.6</springframework.version>
    <com.my.account.version>1.0.0-SNAPSHOT</com.my.account.version>
    <javax.mail.version>1.4.1</javax.mail.version>
    <com.icegreen.version>1.3.1b</com.icegreen.version>
    <junit.version>4.7</junit.version>
    <source.version>1.5</source.version>
    <target.version>1.5</target.version>
  </properties>

  <dependencies> 
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>${junit.version}</version>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>com.my.account</groupId>
      <artifactId>account-common</artifactId>
      <version>${com.my.account.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${springframework.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>${springframework.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${springframework.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context-support</artifactId>
        <version>${springframework.version}</version>
    </dependency>
    <dependency>
        <groupId>javax.mail</groupId>
        <artifactId>mail</artifactId>
        <version>${javax.mail.version}</version>
    </dependency>
    <dependency>
        <groupId>com.icegreen</groupId>
        <artifactId>greenmail</artifactId>
        <version>${com.icegreen.version}</version>
        <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>${source.version}</source>
                <target>${target.version]</target>
            </configuration>
        </plugin>
    </plugins>
  </build>
</project>
优化依赖
    在软件开发过程中，程序员会通过重构等方式不断地优化自己的代码，使其变得更简洁，更灵活。同理对于Maven的依赖我们也可以进行一定程度的优化。

    Maven会自动解析所有项目的直接依赖和传递性依赖，并且根据规则正确判断每个依赖的范围，对于一些依赖冲突，也能进行调节，以确保任何一个构件只有唯一的版本在依赖中存在。在这些工作之后，最后得到的那些依赖被称为已解析依赖。

    可以运行如下命令查看已解析依赖。account-email解析后的依赖如下：

        mvn dependency:list

这里写图片描述

    当这些依赖经Maven解析后就会构成一个依赖树，通过这颗依赖书就能很清楚的看到某个依赖是通过哪条传递路径引入的。可以运行如下命令查看依赖树：

        mvn dependency:tree
    account-email的依赖树如下所示:

这里写图片描述

    使用上面两条命令可以帮助我们了解项目中依赖的具体信息，在此基础上，还可以使用dependency:analyze分析当前项目的依赖，执行如下命令：

        mvn dependency:analyze 
    结果如下所示:

这里写图片描述

    可以看到结果中重要的是[WARNING]，Unused declared dependencies found，意指项目中未使用的，但显式声明的依赖。这里有spring-core和spring-beans。对于这样一类依赖，我们不能简单的直接删除，而是要仔细的分析。由于dependency:analyze只会分析编译主代码和测试代码需要用到的依赖，一些执行测试和运行时需要的依赖就发现不了。以目前的信息来说，我们就不应该删除spring-core和spring-beans这两个依赖。

总结：

    坐标和依赖是Maven中两个核心的概念，弄清楚坐标是什么，依赖是怎么回事，对于我们在日常工作中是至关重要的，重要的是如何定义依赖，以及如何通过Maven的特性对依赖进行管理和优化。
执着的前进
关注
专栏目录
Maven 学习笔记（一）项目构建 | 相关概念 | GAV坐标 | 依赖管理
希望每天都能进步一点点
01-25 1446
文章目录参考资料运行环境一、Maven概述1.1 简介1.2 作用1.3 原理二、Maven相关概念2.1 pom.xml的由来2.2 GAV坐标2.3 构建和自动化构建Maven常见命令以及说明2.4 项目关系2.5 统一管理目标JAR包的版本2.6 依赖管理2.7 配置Maven本地仓库2.8 添加国内阿里云镜像三、基于 IDEA 开发 Maven工程3.1 下载Maven压缩包3.2 设置 Maven3.3 添加Maven工程的两种方式方式一：创建新项目时选择Maven方式二：给当前项目添加Maven
Maven学习笔记
12-21
### Maven学习笔记 #### Maven简介与优势 Maven是一个项目管理和综合工具，主要用来帮助Java项目构建、依赖管理和项目信息管理。与Ant等其他构建工具相比，Maven提供了一种更为标准化的方式，来处理项目的构建过程...
Maven的依赖与最佳配置（转载自Maven实战 作者许晓斌）
ps_zhanglei的专栏
12-20 1234
1、依赖的配置 依赖配置的属性： ... ... ... ... ... ... ... groupId、artifactId和Version：依赖的基本坐标，Maven根据坐标找到相应的依赖。type：依赖的类型，对应于项目坐标定义的packaging。默认为j
maven3实战之坐标和依赖(坐标详解)
fhd001的专栏
06-19 144
maven3实战之坐标和依赖(坐标详解) ---------- maven坐标为各种构件引入了秩序，任何一个构件都必须明确定义自己的坐标，而一组maven坐标是通过一些元素定义的，它们是groupId,artifactId,version,packaging,chassifier。先看一组坐标定义，如下：   &lt;groupId&gt;org.sonatype.nexu...
Maven入门指南③：坐标和依赖
weixin_30793643的博客
06-13 95
1 . 坐标 　　maven 的所有构件均通过坐标进行组织和管理。maven 的坐标通过 5 个元素进行定义，其中 groupId、artifactId、version 是必须的，packaging 是可选的（默认为jar），classifier 是不能直接定义的。 groupId：定义当前 Maven 项目所属的实际项目，跟 Java 包名类似，通常与域名反向一一对应。 artifac...
maven坐标和依赖(一)
odelia的博客
08-01 797
Maven坐标 坐标是Maven实现依赖管理功能的基础，Maven通过为任何一个构件定义一个唯一的标示来确定该构件的归属及版本。Maven的坐标元素包括groupId、artifactId、version、packaging、classfier。 提供了正确的坐标，maven就能找到对应的构件、首先去你的本地仓库查找，没有的话再去远程仓库下载。如果没有配置远程仓库，会默认从中央仓库地址(http
Maven教程-坐标和依赖
Ricky
12-08 2300
Maven教程
maven学习笔记
12-16
**Maven学习笔记** 在Java开发领域，Maven是一个不可或缺的构建工具，它极大地简化了项目的构建、管理和依赖管理过程。Maven通过一个统一的项目对象模型（Project Object Model，POM），使得开发者可以轻松地定义...
Maven学习笔记.zip
10-20
**Maven学习笔记** 在Java开发领域，Maven是一个不可或缺的构建工具，它极大地简化了项目的构建、管理和依赖管理过程。Maven通过使用一个项目对象模型（Project Object Model，POM），XML格式的配置文件，定义了...
maven学习笔记01（基础入门）
08-09
** Maven基础入门 ** Maven是一个Java项目管理工具，它主要负责构建、依赖管理和项目信息管理。...在`maven_study_01`的学习笔记中，你可以找到更多关于Maven的基础知识和实践案例，帮助你快速上手并掌握这一工具。
Maven学习笔记之坐标和依赖
fanxiaobin
01-01 1003
前言：我在写这篇博客的时候也是一名初学者，如果有任何疑问或者发现某处错误，可以留言或者发送邮件到 fanxiaobin.fxb@qq.com ，我会尽快解决并予以回复。 1. Maven坐标   Maven坐标其实与地理坐标类同，就是几个可以唯一确定某个东西的参数。在Maven坐标中有三个是必须定义的（groupId、artifactId、version），一个是可选的（packaging），...
4.Maven依赖管理坐标机制介绍
你好洋一
03-10 218
文章目录1. 坐标介绍2. 企业级的坐标设置3. 坐标作用 1. 坐标介绍 每个maven项目都有自己的一个专门坐标，用于辨识。我们基本通过5个维度来定义唯一依赖包。 五个维度 groupId artifactId version packaging classifier 任何一个项目都离不开这五个维度来定义依赖包。实际上后面两个维度我们很少使用，项目常见依赖定位 groupId + artifactId + version 2. 企业级的坐标设置 groupId 公司或者组织，但是以你的公司或
有关使用junit依赖出现@Before或者@Before注解不生效
Kevinnsm的博客
02-20 2564
有可能是Junit使用版本过高，有两种解决方法: 1.如果Junit使用版本较高，可以使用@BeforeEach和@AfterEach代替@Before和@After 2.降低Junit版本
Junit单元测试_概述、使用步骤、junit依赖环境导入、@Before&@After
weixin_44664432的博客
10-20 1771
测试分类： 黑盒测试：不需要写代码，给输入值，看程序是否能够输出期望的值。 白盒测试：需要写代码的。关注程序具体的执行流程。 Junit使用：白盒测试 步骤： 定义一个测试类(测试用例) 建议： 测试类名：被测试的类名Test CalculatorTest 包名：xxx.xxx.xx.test cn.test 定义测试方法：可以独立运行 建议： 方法名：test测试的方法名 testAdd() 返回值：void 参数列表：空参 给方法加@Test 导入junit依赖环境 判定结
idea添加junit的maven依赖后，使用@Test、@Before、@After仍旧报错问题解决
liu20181029的博客
10-30 1万+
一般该问题是由于jar包的版本存在问题，junit中的test类在4.12版本中是没有的，建议使用4.10版本，maven中的依赖配置如下： &lt;dependency&gt; &lt;groupId&gt;junit&lt;/groupId&gt; &lt;artifactId&gt;junit&lt;/artifactId&gt; &lt;version&gt;4...
java_MAVEN常用坐标
最新发布
Q_W_W_Q的博客
04-27 1688
常用maven坐标。
@Before有啥用
weixin_30293135的博客
08-07 985
@BeforeClass – 表示在类中的任意public static void方法执行之前执行 @AfterClass – 表示在类中的任意public static void方法执行之后执行 @Before – 表示在任意使用@Test注解标注的public void方法执行之前执行 @After – 表示在任意使用@Test注解标注的public void方法执行之后执行 ...
@Before和@After的使用
热门推荐
老婆就是要败家
06-01 3万+
@before的作用就是在一个类中最先执行的方法 @after的作用就是在一个类中最后执行的方法 这样就可以把一些重复执行的代码抽取出来 , 这样我们就不用书写这些的重复的部分了 例如下面的这段代码 , 这是进行查询 ,当我们书写增删改时候还得全部写很麻烦 @Test public void testFindAll() throws Exception { InputStream is = Resources.getResourceAsStream("SqlSessionConfi
使用greenmail测试发送邮件
yzd
08-15 968
1、自定义异常类AccountEmailException public   class  AccountEmailException      extends  Exception {      private   static   final   long  serialVersionUID  =   - 48173864603345016...
Maven入门与依赖管理详解
Maven的核心功能是依赖管理，它解决了Java项目中常见的类库版本控制和管理问题，通过坐标系统确保每个构件的精确定位，并利用中央仓库和Nexus进行快速搜索和下载。 1. Maven简介： Maven作为Java项目的基石，不仅...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值