• Maven pom.xml 元素配置说明(一)


    部分来源:

    1. Maven中 dependencies 节点和 dependencyManagement 节点的区别
    2. dependencies与dependencyManagement的区别
    3. maven profile的使用

    properties

    假如一种场景:比如说spring的jar包版本,由于jar包较多,如果要修改,需要挨个修改,工作量巨大,因此可以使用 <properties>标签,赋值之后,可以统一使用,统一修改。

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-tx</artifactId>
        <version>4.3.5</version>
    </dependency>
    

    转变为

    <properties>
     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
     <spring.version>4.3.5</spring.version>
    </properties>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-tx</artifactId>
        <version>${spring.version}</version>
    </dependency>
    

    dependencyManagement 与 dependencies

    dependencies即使在子项目中不写该依赖项,那么子项目仍然会从父项目中继承该依赖项(全部继承)

    dependencyManagement里只是声明依赖,并不实现引入,因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖,是不会从父项目中继承下来的;只有在子项目中写了该依赖项,并且没有指定具体版本,才会从父项目中继承该项,并且version和scope都读取自父pom;另外如果子项目中指定了版本号,那么会使用子项目中指定的jar版本。

    Itoo-base(pom.xml) 继承于 Itoo-base-parent(pom.xml)
    示例如下:
    Itoo-base-parent(pom.xml)

    <dependencyManagement>  
        <dependencies>  
            <dependency>  
                <groupId>org.eclipse.persistence</groupId>  
                <artifactId>org.eclipse.persistence.jpa</artifactId>  
                <version>${org.eclipse.persistence.jpa.version}</version>  
                <scope>provided</scope>  
            </dependency>  
              
            <dependency>  
                <groupId>javax</groupId>  
                <artifactId>javaee-api</artifactId>  
                <version>${javaee-api.version}</version>  
            </dependency>  
        </dependencies>  
    </dependencyManagement>  
    

    Itoo-base(pom.xml)

    <!--继承父类-->  
    <parent>  
        <artifactId>itoo-base-parent</artifactId>  
        <groupId>com.tgb</groupId>  
    
        <version>0.0.1-SNAPSHOT</version>  
        <relativePath>../itoo-base-parent/pom.xml</relativePath>  
    </parent>  
    <modelVersion>4.0.0</modelVersion>  
    <artifactId>itoo-base</artifactId>  
    <packaging>ejb</packaging>  
          
    <!--依赖关系-->  
    <dependencies>  
    	<dependency>  
            <groupId>javax</groupId>  
            <artifactId>javaee-api</artifactId>  
        </dependency>  
          
        <dependency>  
            <groupId>com.fasterxml.jackson.core</groupId>  
            <artifactId>jackson-annotations</artifactId>  
        </dependency>  
          
        <dependency>  
            <groupId>org.eclipse.persistence</groupId>  
            <artifactId>org.eclipse.persistence.jpa</artifactId>  
            <scope>provided</scope>  
        </dependency>  
    </dependencies>  
    

    请注意:
    子类中没有指明依赖项的版本信息,在顶层 pom 中的 dependencyManagement 中javaee-api表明其优选的版本是 ${javaee-api.version} ,版本信息会注入其中。
    只有当 外层的dependencies 元素中没有指明版本信息时, dependencyManagement 中的 dependencies 元素才起作用。

    这样做的好处:
    统一管理项目的版本号,确保应用的各个项目的依赖和版本一致,才能保证测试的和发布的是相同的成果,因此,在顶层pom中定义共同的依赖关系。同时可以避免在每个使用的子项目中都声明一个版本号,这样想升级或者切换到另一个版本时,只需要在父类容器里更新,不需要任何一个子项目的修改;如果某个子项目需要另外一个版本号时,只需要在dependencies中声明一个版本号即可。子类就会使用子类声明的版本号,不继承于父类版本号。

    顶层 pom 中的 dependencies 与 dependencyManagement 中的 dependencies 元素有一个重要的区别:
    dependencyManagement 中的 dependencies 元素只表明依赖项版本的优先选择,并不影响项目的依赖项;而 dependencies 元素则影响项目的依赖项。

    Profile

    使用maven来实现多环境的构建可移植性,需要借助maven提供的profile功能,通过不同的环境激活不同的profile来达到构建的可移植性。

    一、POM中profile的配置
    首先是profile配置,在pom.xml中添加如下profile的配置:

    <profiles>
    	<profile>
    		<id>dev</id>
    		<properties>
    			<profiles.active>dev</profiles.active>
    		</properties>
    		<activation>
    			<activeByDefault>true</activeByDefault>
    		</activation>
    	</profile>
    	<profile>
    		<id>test</id>
    		<properties>
    			<profiles.active>test</profiles.active>
    		</properties>
    	</profile>
    </profiles>
    

    这里定义了三个环境,dev(开发环境)、test(测试环境),其中开发环境是默认激活的(activeByDefault为true),这样如果在不指定profile时默认是开发环境。

    同时每个profile还定义了两个属性,其中profiles.active表示被激活的profile的配置文件的目录。

    二、工程目录
    针对不同的环境,我们定义不同的配置文件,而这些配置文件都做为资源文件放到maven工程的文件目录下(已将src/main/resources改为config),即config目录下,且各个环境的配置分别放到相应的目录下,而所有环境都公用的配置,直接放到config目录下即可。目录结构如下所示:

    src/main/resources  
    	spring.xml  
    	spring-mvc.xml  
    	properties  
    		dev  
    			dev.properties  
    		test  
    			test.properties  
    

    如上所示,开发环境、测试环境的配置文件分别放到config目录下的dev、test三个子目录中,剩余公共的配置文件放于config目录下。
    三、POM文件中build配置
    在pom中的build节点下,配置资源文件的位置,如下所示:

    <resources>
    	<resource>
    		<directory>config</directory>
    		<excludes>
    			<exclude>properties/dev/*</exclude>
    			<exclude>properties/test/*</exclude>
    		</excludes>
    	</resource>
    	<resource>
    		<directory>config/properties/${profiles.active}</directory>
    	</resource>
    </resources>
    

    首先第一个资源文件位置config需要排队提各个环境的配置文件,各个环境的配置我们在第三个节点中通过前面在profile中配置的profiles.active属性来指定。即config/properties/${profiles.active}。这样在激活指定的profile时,会加载指定目录下的配置文件,如当前激活的是dev profile,那么这个资源目录就是config/properties/dev。这样就达到了不同环境加载不同配置的目的。
    四、项目编译生成
    所有需要的配置就完成了,通过在运行maven命令时指定不同的profile即可构建不同环境需要的war包或发布到不同的环境了 。如:

    mvn clean package -Ptest 即构建出生产环境需要的war包
    

    war包解压后,文件结构如下:

    WEB-INF
    	classes
    		spring.xml
    		spring-mvc.xml
    		test.properties
    

    由于默认的profile是dev,所以如果我们不指定profile,那么加载就是开发环境dev下的配置文件了。即我们在本地开发测试时,不用关心profile的问题。

  • 相关阅读:
    vim 常用命令
    centos 安装mysql
    centos部署ftp
    centos 6.8部署nginx
    ndk学习16: unix domain socket
    ndk学习14: 进程
    ndk学习13: proc
    ndk学习11: linux内存管理
    ndk学习10: linux文件系统
    ndk学习9: 动态使用共享库
  • 原文地址:https://www.cnblogs.com/cuiyf/p/6257346.html
Copyright © 2020-2023  润新知