Maven

Maven内置属性、POM属性 Maven内置属性、POM属性, maven properties 内置属性(Maven预定义，用户可以直接使用) ${basedir}表示项目根目录，即包含pom.xml文件的目录; ${version}表示项目版本; ${project.basedir}同${basedir}; ${project.baseUri}表示项目文件地址; ${maven.build.timestamp}表示项目构件开始时间; ${maven.build.timestamp.format}表示属性${maven.build.timestamp}的展示格式,默认值为yyyyMMdd-HHmm,可自定义其格式,其类型可参考java.text.SimpleDateFormat。 用法： <properties> <maven.build.timestamp.format>yyyy-MM-dd HH:mm:ss</maven.build.timestamp.format> </properties> POM属性(使用pom属性可以引用到pom.xml文件对应元素的值) ${project.build.directory} 项目构建输出目录，默认为target/ ${project.build.outputDirectory} 项目主代码编译输出目录，默认为target/classes/ ${project.build.testOutputDirectory}:项目测试代码编译输出目录，默认为target/testclasses/ ${project.build.sourceEncoding} 表示主源码的编码格式; ${project.build.sourceDirectory} 项目的主源码目录，默认为src/main/java/ ${project.build.testSourceDirectory} 项目的测试源码目录，默认为/src/test/java/ ${project.build.finalName} 表示输出文件名称; ${project.version} 表示项目版本,与${version}相同; ${project.groupId}:项目的groupId ${project.artifactId} 项目的artifactId 用法： <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> ${project.build.outputDirectory}/META-INF/xxx/xxx 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告：代码/配置放入代码块，正文中的尖括号占位符改为行内代码 正文中的 HTML/XML 片段被当作原始 HTML 丢弃；文件名/URL/标题按规范调整

Maven中的DependencyManagement和Dependencies 这里介绍一个在父项目中的根结点中声明dependencyManagement和dependencies的区别 dependencyManagement Maven 使用dependencyManagement 元素来提供了一种管理依赖版本号的方式。通常会在一个组织或者项目的最顶层的父POM 中看到dependencyManagement 元素。使用pom.xml 中的dependencyManagement 元素能让 所有在子项目中引用一个依赖而不用显式的列出版本号。Maven 会沿着父子层次向上走，直到找到一个拥有dependencyManagement 元素的项目，然后它就会使用在这个dependencyManagement 元素中指定的版本号。 例如在父项目里: <dependencyManagement> <dependencies> <dependency> <groupId>MySQL</groupId> MySQL-connector-java</artifactId> <version>5.1.2</version> </dependency> ... <dependencies> </dependencyManagement> 然后在子项目里就可以添加MySQL-connector时可以不指定版本号，例如: <dependencies> <dependency> <groupId>MySQL</groupId> MySQL-connector-java</artifactId> </dependency> </dependencies> 这样做的好处就是: 如果有多个子项目都引用同一样依赖，则可以避免在每个使用的子项目里都声明一个版本号，这样当想升级或切换到另一个版本时，只需要在顶层父容器里更新，而不需要一个一个子项目的修改 ；另外如果某个子项目需要另外的一个版本，只需要声明version就可。 dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显式的声明需要用的依赖。 dependencies 相对于dependencyManagement，所有声明在dependencies里的依赖都会自动引入，并默认被所有的子项目继承。 classifier 如果你要发布同样的代码，但是由于技术原因需要生成两个单独的构件，你就要使用一个分类器 (classifier) 。例如，如果你想要构建两个单独的构件成JAR，一个使用Java 1.4 编译器，另一个使用Java 6 编译器，你就可以使用分类器 来生成两个单独的JAR构件，它们有同样的groupId:artifactId:version组合。如果你的项目使用本地扩展类库，你可以使用分类器为每一个目标平台生成一个构件。分类器常用于打包构件的源码，JavaDoc 或者二进制集合。 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告：代码/配置放入代码块，正文中的尖括号占位符改为行内代码；文件重命名为 maven-dependency-management.md；title 改为「Maven 中的 DependencyManagement 和 Dependencies」；url 改为 maven-dependency-management；旧 url 加入 aliases；categories 改为 Java 正文中的 HTML/XML 片段被当作原始 HTML 丢弃；文件名/URL/标题按规范调整

maven pom 基本内容: POM包括了所有的项目信息。 maven 相关: pom定义了最小的maven2元素，允许groupId,artifactId,version。所有需要的元素 groupId:项目或者组织的唯一标志，并且配置时生成的路径也是由此生成，如org.codehaus.mojo生成的相对路径为: /org/codehaus/mojo artifactId: 项目的通用名称 version:项目的版本 packaging: 打包的机制，如pom, jar, maven-plugin, ejb, war, ear, rar, par classifier: 分类 <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/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.wiloon</groupId> wechat</artifactId> <packaging>jar</packaging> <version>1.0-SNAPSHOT</version> <name>wechat</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>junit</groupId> junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project> compile plugin, war plugin, specify jdk version <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> maven-compiler-plugin</artifactId> <configuration> <source>1.7</source> <target>1.7</target> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> </plugin> </plugins> </build> 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告：代码/配置放入代码块，正文中的尖括号占位符改为行内代码；categories 改为 Java 正文中的 HTML/XML 片段被当作原始 HTML 丢弃；文件名/URL/标题按规范调整

命令行 创建多模块的Maven项目(父模块,子模块) 我们都知道,我们常常将一个复杂的java应用拆分成多个java子应用。由于maven的出现,这种拆分就更加容易了,因为我们通过maven可以创建多个关联模块的项目 (Multiple Module Projects) 。由一个总的模块,下面包含多个子模块 (子模块还可以包含子模块) 。 一、通过在Maven命令行创建。 创建父模块 (总的POM) - cms-validator 使用命令mvn archetype:create -DgroupId=com.ebay.tools.cms.validator -DartifactId=cms-validator 创建一个maven项目,然后修改该项目的pom.xml文件,将package类型改为pom <packaging>pom</packaging> 并删除其中的src目录。 cd cms-validator 创建提供rest service的子模块: validator-rest 在父模块的目录下, 使用命令mvn archetype:create -DgroupId=com.ebay.tools.cms.validator.rest -DartifactId=validator-rest 创建一个maven (子) 项目。 创建一个web子模块: validator-web 在父模块的目录下, mvn archetype:create -DgroupId=com.ebay.tools.cms.validator.web -DartifactId=validator-web -DarchetypeArtifactId=maven-archetype-webapp 完成以上3步以后,会在总的pom.xml中已经自动加入: <modules> <module>validator-rest</module> <module>validator-web</module> </modules> 在各个子模块中也自动的加入了: <parent> <artifactId>cms-validator</artifactId> <groupId>com.ebay.tools.cms.validator</groupId> <version>1.0-SNAPSHOT</version> </parent> 由于默认情况下子模块继承了总POM的package(pom),这里需要修改子模块的pom的package类型。 validator-web模块覆盖为<packaging>war</packaging>, validator-rest模块修改为: <packaging>jar</packaging>。 对父模块的特别设置: 需要在上级模块中设置java编译的参数,现在eclipse一般都使用比较新的版本,默认jdk是1.6,而maven默认的Jdk版本很有可能还是1.4。 所以需要设置java编译参数。 <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> <encoding>UTF-8</encoding> </configuration> </plugin> 如果web子模块需要wtp的支持,则可以在web模块的pom中设置wtp的支持,需要设置elcipse插件: <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-eclipse-plugin</artifactId> <configuration> <wtpmanifest>true</wtpmanifest> <wtpapplicationxml>true</wtpapplicationxml> <wtpversion>2.0</wtpversion> </configuration> </plugin> </plugins> </build> 生成eclipse项目: 在父模块的根目录下,执行命令: ...

maven setting, mirror, repository maven mirror, repository mirror和 repository 1 Repository (仓库) 1.1 Maven仓库主要有2种: remote repository: 相当于公共的仓库，大家都能访问到，一般可以用URL的形式访问 local repository: 存放在本地磁盘的一个文件夹，例如，windows上默认是C:\Users\｛用户名｝.m2\repository目录 1.2 Remote Repository主要有3种: 中央仓库: http://repo1.maven.org/maven2/ 私服: 内网自建的maven repository，其URL是一个内部网址 其他公共仓库: 其他可以互联网公共访问maven repository，例如 jboss repository等 repository里存放的都是各种jar包和maven插件。当向仓库请求插件或依赖的时候，会先检查local repository，如果local repository有则直接返回，否则会向remote repository请求，并缓存到local repository。也可以把做的东西放到本地仓库，仅供本地使用；或上传到远程仓库，供大家使用。 2 Mirror mirror相当于一个拦截器，它会拦截maven对remote repository的相关请求，把请求里的remote repository地址，重定向到mirror里配置的地址。 2.1 没有配置mirror: 2.2 配置mirror: 此时，B Repository被称为A Repository的镜像。 如果仓库X可以提供仓库Y存储的所有内容，那么就可以认为X是Y的一个镜像。换句话说，任何一个可以从仓库Y获得的构件，都胡够从它的镜像中获取。 2.3 <mirrorOf></mirrorOf> <mirrorOf></mirrorOf>标签里面放置的是要被镜像的Repository ID。为了满足一些复杂的需求，Maven还支持更高级的镜像配置: <mirrorOf>*</mirrorOf> 匹配所有远程仓库。 <mirrorOf>repo1,repo2</mirrorOf> 匹配仓库repo1和repo2，使用逗号分隔多个远程仓库。 <mirrorOf>*,!repo1</mirrorOf> 匹配所有远程仓库，repo1除外，使用感叹号将仓库从匹配中排除。 3 Repository与Mirror 3.1 定义 其实，mirror表示的是两个Repository之间的关系，在maven配置文件 (setting.xml)里配置了<mirrors><mirror>……….</mirror></mirrors>，即定义了两个Repository之间的镜像关系。 3.2 目的 配置两个Repository之间的镜像关系，一般是出于访问速度和下载速度考虑。 例如， 有一个项目，需要在公司和住所都编码，并在项目pom.xml配置了A Maven库。在公司，是电信网络，访问A库很快，所以maven管理依赖和插件都从A库下载；在住所，是网通网络，访问A库很慢，但是访问B库很快。这时，在住所的setting.xml里，只要配置一下<mirrors><mirror>….</mirror></mirrors>，让B库成为A库的mirror，即可不用更改项目pom.xml里对于A库的相关配置。 ...

Maven构建之依赖传递 http://a123159521.iteye.com/blog/774322 博客分类: Maven mavenjunit项目管理配置管理Apache 如果断Maven的依赖构建必须每一个项目都指定,那配置是累死人了,比如A依赖了20个项目,B依赖A,那么还要添加20个项目,那就悲剧了,maven有依赖传递的功能。 Transitive Dependency (传递依赖) 你的项目依赖于A,A又依赖于B。你的项目是否要声明你依赖于B？ Maven的回答是它帮你自动管理这种依赖的传递,你不需要声明你依赖于B,由Maven来做。 [版本还是要自己指定的.] Dependency Scope (依赖范围) 因此,Maven考虑了6中可能的scope供选择: compile: 默认的scope。编译、测试、打包全都需要。compile参与依赖传递,就是说,你的项目A依赖于B(依赖scope是compile),项目C依赖于你的项目A,那么C也就依赖于B。 provided: 表示JDK或者容器会在Runtime时提供这些(jar),如上面说到的servlet api。provided的东西在编译和测试时会用到,不参与传递依赖。 runtime: 表示编译时不需要,但测试和运行时需要,最终打包时会包含进去。 test: 只用于测试阶段 (测试的编译和测试的运行) ,典型的就是junit的jar。 system: 和provided类似,但要求jar是你的系统里已有的,不会在repository里找,如rt.jar,tools.jar这些。 import: 简单的说,你的项目的pom可以继承另一个项目的pom,从而继承了父项目的依赖关系,但是因为之后single inheritance的限制,所以创造了import,使得你可以"导入"或者说"继承"任何一到多个项目的依赖关系。 依赖管理(dependencyManagement) 实际的项目中,你会有一大把的Maven模块,而且你往往发现这些模块有很多依赖是完全项目的,A模块有个对spring的依赖,B模块也有,它们的依赖配置一模一样,同样的groupId, artifactId, version,或者还有exclusions, classifer。细心的分会发现这是一种重复,重复就意味着潜在的问题,Maven提供的dependencyManagement就是用来消除这种重复的。 为了实现项目间的依赖,一般情况下,web项目依赖于app项目,而app项目很可能依赖于其他的app项目,比如我建了一个util项目,app依赖于util,那么webapp也需要依赖于util,但是我不配置webapp依赖util,验证一下,会不会自动加载依赖包. util项目的构建请参照前讲,接下来看maven配置: util配置; <?xml version="1.0" encoding="UTF-8"?> <project xsi:schemaLocation="<http://maven.apache.org/POM/4.0.0> [http://maven.apache.org/xsd/maven-4.0.0.xsd](http://maven.apache.org/xsd/maven-4.0.0.xsd)" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <modelVersion>4.0.0</modelVersion> <parent> demo</artifactId> <groupId>com.test</groupId> <version>1.0.0-SNAPSHOT</version> </parent> <groupId>com.test.util</groupId> util</artifactId> <version>1.0-SNAPSHOT</version> <name>util</name> <url><http://maven.apache.org>[/url](/url) <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> </plugins> </build> <dependencies> <dependency> <groupId>junit</groupId> junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> </project> app项目的maven配置: ...

Maven http://juvenshun.iteye.com/blog/376422 什么是版本管理 首先,这里说的版本管理 (version management) 不是指版本控制 (version control) ,但是本文假设你拥有基本的版本控制的知识,了解subversion的基本用法。版本管理中说得版本是指构件 (artifact) 的版本,而非源码的版本 (如subversion中常见的rXXX,或者git中一次提交都有个sha1的commit号) 。 比如我有一个项目,其artifactId为myapp,随着项目的进展,我们会生成这样一些jar: myapp-1.0-SNAPSHOT.jar,myapp-1.0.jar,myapp-1.1-SNAPSHOT.jar,myapp-1.0.1.jar等等。你可能会说,这很简单啊,我在POM中改个version,mvn clean install不就完了？但这只是表面,本文我将讲述,snapshot和release版本的区别,如何自动化版本发布 (如果你的项目有几十个module,你就会觉得手工改POM来升级版本是很痛苦的事情) ,结合自动化发布的过程,这里还会介绍maven-release-plugin。此外,一些scm概念也会被涉及到,比如tag和branch。 前提: 版本控制 不管怎样,我们都需要建立一个项目并提交到SCM中,这里我以subversion为例。你得有一个配置好的subversion repository,这里我建立了一个空的svn仓库,其地址为: https://192.168.1.100:8443/svn/myapp/ 现在,该目录下只有三个空的典型的子目录: /trunk/, branches/, tags/。分别用来存放主干,分支,以及标签。 接着将项目导入到svn仓库中,到项目根目录,运行如下命令: svn import -m 'project initialization' https://192.168.1.100:8443/svn/myapp/trunk (注意,这么做你会将目录下所有文件导入到svn库中,但是这其中某些目录和文件是不应该被导入的,如/target目录,以及eclipse相关的项目文件) 目前,我们将项目的版本设置为1.0-SNAPSHOT。 为什么用SNAPSHOT？ 我先说说如果没有SNAPSHOT会是什么样子。假设你的项目有2个模块,A,B,其中A依赖B。这两个模块分别由甲,乙两个个人负责开发。在开发过程中,因为A是依赖于B的,因此乙每次做一个改动都会影响到甲,于是,乙提交了一些更改后,需要让甲看到。这个时候,怎么做呢？乙对甲说,“你签出我的代码,build一下就OK了”,甲有点不情愿,但还是照做了,签出代码,svn clean install,然后,发现build出错了,有个测试没有pass。甲郁闷了,对乙说,“你的代码根本不能用,我不想build,你build好了给我”,乙看了看确实自己的代码build不过,于是回去解决了,然后打了个jar包,扔给甲,甲对了对groupId,artifactId,放到了自己的.m2/repository/目录下,OK,能用了。 于是乙每次更新都这样做,打包,复制,然后甲粘贴,使用……渐渐的,大家发现这是个很笨的办法,这是纯手工劳动阿,程序员最BS的就是重复劳动。一天,甲对乙说,“你知道nexus么？你把你的jar发布到nexus上就可以了,我要用就自动去下载,这多棒！“乙说"哦？有这好东西,我去看看"于是乙发现了nexus这块新大陆,并成功的发布了B到nexus上。 (见,Nexus入门指南, (图文) ) 。 但是,请注意,我们这里的一切都假设没有SNAPSHOT,因此如果乙不更改版本,甲下载一次如B-1.0.jar之后,maven认为它已经有了正确的B的版本,就不会再重新下载。甲发现了这个问题,对乙说"你的更新我看不到,你更新了么？“乙说"不可能！我看看”,于是检查一下甲下载的C-1.0.jar,发现那是几天前的。乙一拍脑袋,说"这简单,我更新一下我的版本就好了,我发布个B-1.1.jar上去,你更新下依赖版本”,甲照做了,似乎这么做是可行的。 这里有一个问题,一次提交就更新一个版本,这明显不是正确的管理办法,此外,乙得不停的通知甲更新对B的依赖版本,累不累阿？1.0,或者说1.1,2.0,都代表了稳定,这样随随便便的改版本,能稳定么？ 所以Maven有SNAPSHOT版本的概念,它与release版本对应,后者是指1.0,1.1,2.0这样稳定的发布版本。 现在乙可以将B的版本设置成1.0-SNAPSHOT,每次更改后,都mvn deploy到nexus中,每次deploy,maven都会将SNAPSHOT改成一个当前时间的timestamp,比如B-1.0-SNAPSHOT.jar到nexus中后,会成为这个样子: B-1.0-20081017-020325-13.jar。Maven在处理A中对于B的SNAPSHOT依赖时,会根据这样的timestamp下载最新的jar,默认Maven每天 更新一次,如果你想让Maven强制更新,可以使用-U参数,如: mvn clean install -U 。 现在事情简化成了这个样子: 乙做更改,然后mvn deploy,甲用最简单的maven命令就能得到最新的B。 从1.0-SNAPSHOT到1.0到1.1-SNAPSHOT SNAPSHOT是快照的意思,项目到一个阶段后,就需要发布一个正式的版本 (release版本) 。一次正式的发布需要这样一些工作: 在trunk中,更新pom版本从1.0-SNAPSHOT到1.0 对1.0打一个svn tag 针对tag进行mvn deploy,发布正式版本 更新trunk从1.0到1.1-SNAPSHOT 你可以手工一步步的做这些事情,无非就是一些svn操作,一些pom编辑,还有一些mvn操作。但是你应该明白,手工做这些事情,一来繁琐,而来容易出错。因此这里我介绍使用maven插件来自动化这一系列动作。 SCM ...

Maven jar plugin 1.修改pom.xml增加如下内容 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>2.4</version> <configuration> <manifest> true</addClasspath> <classpathPrefix>lib/</classpathPrefix> <mainClass>com.sysware.HelloWorld</mainClass> </manifest> </archive> </configuration> </plugin> 运行mvn clean package即可 <build> <finalName>...</finalName> <sourceDirectory>src/main/java</sourceDirectory> <resources> <!-- 控制资源文件的拷贝 --> <resource> <directory>src/main/resources</directory> <targetPath>${project.build.directory}</targetPath> </resource> </resources> <plugins> <!-- 设置源文件编码方式 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <defaultLibBundleDir>lib</defaultLibBundleDir> <source>1.6</source> <target>1.6</target> <encoding>UTF-8</encoding> </configuration> </plugin> <!-- 打包jar文件时，配置manifest文件，加入lib包的jar依赖 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> <mainClass>.....MonitorMain</mainClass> </manifest> </archive> </configuration> </plugin> <!-- 拷贝依赖的jar包到lib目录 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>copy</id> <phase>package</phase> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <outputDirectory> ${project.build.directory}/lib </outputDirectory> </configuration> </execution> </executions> </plugin> <!-- 解决资源文件的编码问题 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-resources-plugin</artifactId> <version>2.3</version> <configuration> <encoding>UTF-8</encoding> </configuration> </plugin> <!-- 打包source文件为jar文件 --> <plugin> <artifactId>maven-source-plugin</artifactId> <version>2.1</version> <configuration> <attach>true</attach> <encoding>UTF-8</encoding> </configuration> <executions> <execution> <phase>compile</phase> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> </plugins> </build> <build> <resources> <resource> <targetPath>${project.build.directory}/classes</targetPath> <directory>src/main/resources</directory> <filtering>true</filtering> <includes> <include>**/*.xml</include> </includes> </resource> </resources> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.0</version> <configuration> <source>1.6</source> <target>1.6</target> <encoding>UTF-8</encoding> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>2.0</version> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>com.test.testguava.app.App</mainClass> </transformer> <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> <resource>applicationContext.xml</resource> </transformer> </transformers> <shadedArtifactAttached>true</shadedArtifactAttached> <shadedClassifierName>executable</shadedClassifierName> </configuration> </execution> </executions> </plugin> </plugins> </build> 地址: http://blog.csdn.net/johnnywww/article/details/7964326 ...

maven Scope maven依赖关系中Scope的作用 Dependency Scope 在 POM 4 中，<dependency> 中还引入了 <scope>，它主要管理依赖的部署。目前 <scope> 可以使用 5 个值: compile，缺省值，适用于所有阶段，会随着项目一起发布。 provided，类似compile，期望JDK、容器或使用者会提供这个依赖。如servlet.jar。 runtime，只在运行时使用，如JDBC驱动，适用运行和测试阶段。 test，只在测试时使用，用于编译和运行测试代码。不会随项目发布。 system，类似provided，需要显式提供包含依赖的jar，Maven不会在Repository中查找它。 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告：代码/配置放入代码块，正文中的尖括号占位符改为行内代码；categories 改为 Java 正文中的 HTML/XML 片段被当作原始 HTML 丢弃；文件名/URL/标题按规范调整

appassembler-maven-plugin Goals Overview [appassembler:assemble][1] Assembles the artifacts and generates bin scripts for the configured applications. [appassembler:create-repository][2] Creates an appassembler repository. [appassembler:generate-daemons][3] Generates JSW based daemon wrappers. maven 自动生成运行脚本插件appassembler-maven-plugin 博客分类: maven appassembler-maven-plugin可以自动生成跨平台的启动脚本,省去了手工写脚本的麻烦,而且还可以生成jsw的后台运行程序。 appassembler的配置比较简单,在pom.xml的配置文件加入插件配置。 比如说不同的启动脚本,可以如下配置 <plugin> <groupId>org.codehaus.mojo</groupId> appassembler-maven-plugin</artifactId> <version>1.2.1</version> <configuration> <configurationDirectory>conf</configurationDirectory> <configurationSourceDirectory>src/main/resources</configurationSourceDirectory> <copyConfigurationDirectory>true</copyConfigurationDirectory> <includeConfigurationDirectoryInClasspath>true</includeConfigurationDirectoryInClasspath> ${project.build.directory}/chj-search-client</assembleDirectory> <extraJvmArguments>-Xms128m</extraJvmArguments> <binFileExtensions> <unix>.sh</unix> </binFileExtensions> <platforms> <platform>windows</platform> <platform>unix</platform> </platforms> <repositoryName>lib</repositoryName> <programs> <program> <mainClass>com.chj360.search.client.App</mainClass> </program> </programs> </configuration> </plugin> 然后运行maven命令 :mvn package appassembler:assemble 就可以自动生成整个的依赖文件,配置文件和运行脚本了。 一些配置说明 configurationDirectory: 生成配置文件路径 configurationSourceDirectory: 配置文件原路径,默认为src/main/config assembleDirectory:整体包目录 ...

maven profile http://haohaoxuexi.iteye.com/blog/1900568 4 profile介绍 4.1 profile简介 profile可以让我们定义一系列的配置信息,然后指定其激活条件。这样我们就可以定义多个profile,然后每个profile对应不同的激活条件和配置信息,从而达到不同环境使用不同配置信息的效果。比如说,我们可以通过profile定义在jdk1.5以上使用一套配置信息,在jdk1.5以下使用另外一套配置信息；或者有时候我们可以通过操作系统的不同来使用不同的配置信息,比如windows下是一套信息,linux下又是另外一套信息,等等。具体的激活条件有哪些我在后文会讲到。 4.2 profile的定义位置 对于使用Maven3,我们可以有多个地方定义profile。定义的地方不同,它的作用范围也不同。 (1) 针对于特定项目的profile配置我们可以定义在该项目的pom.xml中。 (2) 针对于特定用户的profile配置,我们可以在用户的settings.xml文件中定义profile。该文件在用户家目录下的".m2"目录下。 (3) 全局的profile配置。全局的profile是定义在Maven安装目录下的"conf/settings.xml"文件中的。 4.3 profile中能定义的信息 profile中能够定义的配置信息跟profile所处的位置是相关的。以下就分两种情况来讨论,一种是定义在settings.xml中,另一种是定义在pom.xml中。 4.3.1 profile定义在settings.xml中 当profile定义在settings.xml中时意味着该profile是全局的,它会对所有项目或者某一用户的所有项目都产生作用。因为它是全局的,所以在settings.xml中只能定义一些相对而言范围宽泛一点的配置信息,比如远程仓库等。而一些比较细致一点的需要根据项目的不同来定义的就需要定义在项目的pom.xml中。具体而言,能够定义在settings.xml中的信息有 <repositories>、<pluginRepositories>和<properties>。定义在<properties>里面的键值对可以在pom.xml中使用。 4.3.2 profile定义在pom.xml中 定义在pom.xml中的profile可以定义更多的信息。主要有以下这些: <repositories> <pluginRepositories> <dependencies> <plugins> <properties> <dependencyManagement> <distributionManagement> 还有build元素下面的子元素,主要包括: <defaultGoal> <resources> <testResources> <finalName> 4.4 profile的激活方式 Maven给我们提供了多种不同的profile激活方式。比如我们可以使用-P参数显示的激活一个profile,也可以根据环境条件的设置让它自动激活等。下面将对它们一一进行介绍: 4.4.1 使用activeByDefault设置激活 先看下面一个配置 <profiles> <profile> <id>profileTest1</id> <properties> <hello>world</hello> </properties> true</activeByDefault> </activation> </profile> <profile> <id>profileTest2</id> <properties> <hello>andy</hello> </properties> </profile> </profiles> 我们可以在profile中的activation元素中指定激活条件,当没有指定条件,然后指定activeByDefault为true的时候就表示当没有指定其他profile为激活状态时,该profile就默认会被激活。所以当我们调用mvn package的时候上面的profileTest1将会被激活,但是当我们使用mvn package –P profileTest2的时候将激活profileTest2,而这个时候profileTest1将不会被激活。 4.4.2 在settings.xml中使用activeProfiles指定处于激活状态的profile 我们可以在settings.xml中使用activeProfiles来指定需要激活的profile,这种方式激活的profile将所有情况下都处于激活状态。比如现在我们定义了如下两个profile <profiles> <profile> <id>profileTest1</id> <properties> <hello>world</hello> </properties> </profile> <profile> <id>profileTest2</id> <properties> <hello>andy</hello> </properties> </profile> </profiles> 这里的profile可以是定义在settings.xml中的,也可以是定义在pom.xml中的。这个时候如果我们需要指定profileTest1为激活状态,那么我们就可以在settings.xml中定义activeProfiles,具体定义如下: ...

Maven类包冲突终极三大解决技巧 mvn dependency,tree http://ian.wang/106.htm Maven对于新手来说是《步步惊心》,因为它包罗万象,博大精深,因为当你初来乍到时,你就像一个进入森林的陌生访客一样迷茫。 Maven对于老手来说是《真爱配方》,因为它无所不能,利如刀锋,使用Maven做开发,如饮美酒如悦美人。 Maven对于新手来说,最痛苦的一件事莫过于包之间的冲突,由于Maven的依赖传递性,当你引入一个依赖类时,其身后的依赖类也一起如过江之鲫纷至沓来了。 举例 A依赖于B及C,而B又依赖于X、Y,而C依赖于X、M,则A除引B及C的依赖包下,还会引入X,Y,M的依赖包 (一般情况下了,Maven可通过<scope>等若干种方式控制传递依赖) 。 这里有一个需要特别注意的,即B和C同时依赖于X,假设B依赖于X的1.0版本,而C依赖于X的2.0版本,A究竟依赖于X的1.0还是2.0版本呢？ 这就看Classloader的加载顺序了,假设Classloader先加载X_1.0,而它就不会再加载X_2.0了,如果A恰恰希望使用X_2.0呢,血案就这样不期而遇了。 三大技巧 第一板斧:找到传递依赖的鬼出在哪里？ dependency:tree是把照妖照,pom.xml用它照照,所有传递性依赖都将无处遁形,并且会以层级树方式展现,非常直观。 以下就是执行dependency:tree后的一个输出: 引用 [INFO] - maven-dependency-plugin:2.1:tree (default-cli) @ euler-foundation - [INFO] com.hsit:euler-foundation:jar:0.9.0.1-SNAPSHOT [INFO] +- com.rop:rop:jar:1.0.1:compile [INFO] | +- org.slf4j:slf4j-api:jar:1.7.5:compile [INFO] | +- org.slf4j:slf4j-log4j12:jar:1.7.5:compile [INFO] | +- log4j:log4j:jar:1.2.16:compile [INFO] | +- commons-lang:commons-lang:jar:2.6:compile [INFO] | +- commons-codec:commons-codec:jar:1.6:compile [INFO] | +- javax.validation:validation-api:jar:1.0.0.GA:compile [INFO] | +- org.hibernate:hibernate-validator:jar:4.2.0.Final:compile [INFO] | +- org.codehaus.jackson:jackson-core-asl:jar:1.9.5:compile [INFO] | +- org.codehaus.jackson:jackson-mapper-asl:jar:1.9.5:compile [INFO] | +- org.codehaus.jackson:jackson-jaxrs:jar:1.9.5:compile [INFO] | +- org.codehaus.jackson:jackson-xc:jar:1.9.5:compile ...

maven 依赖 继承 Project A 被 Project B 调用 比如 A 里有 mockito的jar包, B要引用A , 从而不需要在B里直接引用mockito的jar包,而且A 包里的自建代码也可以用起来。 关键点在于 A 的pom里不能 用 test scope来藏起来A里面的jar ,这样B就无法继承到了。 Maven依赖范围及依赖传递 一: 依赖范围scope 共5种,compile (编译)、test (测试)、runtime (运行时)、provided、system 不指定,则依赖范围默认为compile. compile:编译依赖范围,在编译,测试,运行时都需要。 test: 测试依赖范围,测试时需要。编译和运行不需要。如Junit runtime: 运行时依赖范围,测试和运行时需要。编译不需要。如JDBC驱动包 provided:已提供依赖范围,编译和测试时需要。运行时不需要。如servlet-api system:系统依赖范围。本地依赖,不在maven中央仓库。 二: 依赖的传递 A->B(compile) 第一关系: a依赖b compile B->C(compile) 第二关系: b依赖c compile 当在A中配置 <dependency> <groupId>com.B</groupId> B</artifactId> <version>1.0</version> </dependency> 则会自动导入c包。关系传递如下表: 第一 第二 compile test provided runtime compile compile runtime test test test ...

gradle maven snapshot configurations.all { // check for updates every build resolutionStrategy.cacheChangingModulesFor 0, ‘seconds’ } dependencies { compile group: “group”, name: “projectA”, version: “1.1-SNAPSHOT”, changing: true } https://discuss.gradle.org/t/how-to-get-gradle-to-download-newer-snapshots-to-gradle-cache-when-using-an-ivy-repository/7344 gradle maven plugin https://docs.gradle.org/current/userguide/publishing_maven.html#header gradle v5.3.1 group = "com.wiloon.group0" version = "0.0.1-SNAPSHOT" plugins { `java-library` `maven-publish` id("com.gradle.build-scan") version "2.2.1" } tasks.register<Jar>("sourcesJar") { from(sourceSets.main.get().allJava) archiveClassifier.set("sources") } tasks.register<Jar>("javadocJar") { from(tasks.javadoc) archiveClassifier.set("javadoc") } publishing { publications { create<MavenPublication>("maven") { from(components["java"]) artifact(tasks["sourcesJar"]) artifact(tasks["javadocJar"]) } } repositories { maven { val releasesRepoUrl = "http://nexus.wiloon.com/repository/maven-releases" val snapshotsRepoUrl = "http://nexus.wiloon.com/repository/maven-snapshots" url = uri(if (version.toString().endsWith("SNAPSHOT")) snapshotsRepoUrl else releasesRepoUrl) credentials { username = "admin" password = "password" } } } } 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告：代码/配置放入代码块，正文中的尖括号占位符改为行内代码；categories 改为 Java 正文中的 HTML/XML 片段被当作原始 HTML 丢弃；文件名/URL/标题按规范调整

maven plugins, pluginManagement https://www.jianshu.com/p/49acf1246eff 1.plugins和pluginManagement的区别概述 plugins 和 pluginManagement 的区别,和我们前面研究过的 dependencies 和 dependencyManagement 的区别是非常类似的。plugins 下的 plugin 是真实使用的,而 pluginManagement 下的 plugins 下的 plugin 则仅仅是一种声明,子项目中可以对 pluginManagement 下的 plugin 进行信息的选择、继承、覆盖等。 2.pluginManagement使用实战 假如存在两个项目,项目A为项目B的父项目,其关系通过pom文件的关系确定。项目A的父pom文件片段如下: <pluginManagement> <plugins> <plugin> <groupId>``org.apache.maven.plugins</groupId> maven-source-plugin</artifactId> <version>2.1</version> <configuration> true</attach> </configuration> <executions> <execution> <phase>compile</phase> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> </plugins> </pluginManagement> 如果项目B也想使用该plugin配置,则在项目B的子pom文件中只需要如下配置: <plugins> <plugin> <groupId>``org.apache.maven.plugins</groupId> maven-source-plugin</artifactId> </plugin> </plugins> 我们可以看到,子pom文件中,省去了版本、配置细节等信息,只需要指定groupId和artifactId,其他信息均从父pom文件继承。当然,如果子pom文件想定制自己的特定内容,可以另行设置,并会覆盖从父pom文件继承到的内容。 需要注意的是,dependencies 和 dependencyManagement 均是 project 下的直接子元素,但是 plugins 和 pluginManagement 却是 project 下 build 的直接子元素。 ...

Maven Dependency Version 依赖版本自动升级 [1.15.0,2.0.0) x>=1.15.0 && x<2.0.0 依赖调节是为了解决版本不一致的问题(multiple versions),并采取就近原则(nearest definition)。 举例来说，A项目通过依赖传递依赖了两个版本的D: A -> B -> C -> ( D 2.0 ) , A -> E -> ( D 1.0 ) 复制代码那么最终A依赖的D的version将会是1.0，因为1.0对应的层级更少，也就是更近。 除了我们常用的<version>1.1.0</version>，在声明依赖版本的时候，可以通过表达式灵活地配置版本号。 例如配置jar包x的<version>标签支持如下几种语法: 1.0: 推荐依赖版本，此版本号可能会被覆盖。 复制代码还可以控制依赖的版本范围: (,1.0]: x <= 1.0 [1.2,1.3]: 1.2 <= x <= 1.3 [1.0,2.0): 1.0 <= x < 2.0 [1.5,): x >= 1.5 复制代码同时声明多个版本范围也是可以的，只要用逗号分隔即可: (,1.0],[1.2,): x <= 1.0 或者 x >= 1.2 复制代码当你不希望依赖某个版本的时候，可以声明为: (,1.1),(1.1,) 举例来说，你想依赖Apache的commons-math3的最新稳定版，而且不想每次有了新的版本手动去升级pom.xml，可以使用如下<version>配置: <dependency> <groupId>org.apache.commons</groupId> commons-math3</artifactId> <version>[3.+,)</version> </dependency> 复制代码编译项目，你会看到项目中依赖的版本为当前(2019/03/04)最新的正式版: 3.6.1。 ...

Spring Boot 是什么 Spring Boot 是 Pivotal （现为 VMware/Broadcom）在 2014 年推出的框架，建立在 Spring Framework 之上，目标是简化整个 Spring 生态的开发、配置和部署。它不只是简化 Spring MVC，同样简化了 Spring Data（数据库访问）、Spring Security（认证授权）、Spring Messaging（消息队列）等全家桶的配置。 核心理念是 “约定优于配置”（Convention over Configuration）：框架提前定好"默认约定"，只要遵循这些约定，就不需要写任何配置；只有想偏离默认行为时，才需要显式配置。 例如，classpath 里有 spring-boot-starter-web，Spring Boot 就约定你要启动一个 Web 服务，自动完成：注册 DispatcherServlet、内嵌 Tomcat 监听 8080 端口、注册 Jackson 用于 JSON 序列化。你什么都不写，java -jar app.jar 就能跑起来。需要覆盖默认行为时，只在 src/main/resources/application.yml 中写偏离默认值的部分： server: port: 9090 # 只需声明偏离默认值的配置 也可通过命令行参数临时覆盖：java -jar app.jar --server.port=9090，优先级高于 application.yml。 出现背景 Spring Boot（2014）与微服务架构的兴起同期出现。2014 年 Martin Fowler 发表了微服务架构的奠基性文章，微服务要求每个服务独立部署、快速启动、进程隔离。传统的 WAR 包 + 外部 Tomcat 的部署方式与这一需求存在明显矛盾，Spring Boot 正是为了解决这一问题而生。 ...

Classpath 是什么 Classpath（类路径） 是 JVM 在运行时查找 .class 文件和 JAR 包的搜索路径集合。当代码里出现 new Foo() 或 Foo.class 时，类加载器要把 com.example.Foo 这个名字解析成磁盘上的 com/example/Foo.class 字节码，去哪里找，就由 classpath 决定。 可以把它理解成「类的 PATH 环境变量」：shell 的 PATH 决定 ls、git 这些命令去哪些目录找可执行文件；JVM 的 classpath 决定加载类时去哪些目录和 JAR 里找字节码。 一条 classpath 由多个条目组成，每个条目是一个目录或一个 JAR/ZIP 文件： 目录条目：以该目录为根，按包名展开找 .class（如条目 target/classes + 类 com.foo.Bar → 找 target/classes/com/foo/Bar.class） JAR 条目：把 JAR 当成一个打包的目录，在其中按同样规则找 分隔符与操作系统有关：Linux/macOS 用冒号 :，Windows 用分号 ;。 如何设置 classpath 按优先级从高到低，常见几种方式： 方式 写法 说明 -cp / -classpath java -cp app.jar:lib/* com.foo.Main 命令行显式指定，最常用；详见 java -cp CLASSPATH 环境变量 export CLASSPATH=... 全局生效，易污染，现代项目基本不用 可执行 JAR 的 Class-Path MANIFEST.MF 里的 Class-Path: JAR 内清单声明依赖；见 MANIFEST.MF 默认值 不指定时为当前目录 . 仅在没有任何设置时 -cp 支持通配符 lib/*（匹配该目录下所有 JAR，但不递归子目录），但不能写成 lib/*.jar。指定了 -cp 后默认的当前目录 . 会失效，需要的话要显式写进去。 ...

背景 Spring Boot 把应用打成单个可执行 JAR，java -jar app.jar 即可启动内嵌 Tomcat（或 Jetty/Undertow）与全部依赖。这与传统「WAR 部署到外部 Tomcat、classpath 由容器管理」不同，也不同于 Maven jar-with-dependencies 那种把依赖 class 解压合并进一个 jar 的做法。 本文说明 Spring Boot 可执行 JAR 的内部布局、JarLauncher 如何启动应用，以及 repackage / bootJar 如何生成该产物。容器镜像、分层 JAR、Buildpack 等部署话题见 Spring Boot Container Packaging；框架层面的「内嵌服务器 + 可执行 JAR」见 Spring Boot。 Thin jar 与 fat jar Fat jar、uber jar、executable jar 在 Spring Boot 语境下指同一件事：一个「全包」可执行 jar。Fat jar 与 uber jar 只是不同叫法（uber 来自德语 über，意为「之上 / 全部」）；Spring 官方文档更常写 executable jar。 与 Maven/Gradle 默认打出的普通 jar（常称 thin jar / plain jar）对比如下： ...

Gradle, 目录 Gradle 是以 Groovy / Kotlin DSL 为基础的 JVM 自动化构建工具，面向 Java 等语言项目。常见构建脚本为 build.gradle（Groovy）或 build.gradle.kts（Kotlin DSL）。 Gradle 与 Gradle Wrapper（gradlew） 很多人第一次 clone 项目时会疑惑：明明没装 Gradle，为什么 ./gradlew test 也能跑？ 答案就在 Wrapper。 是什么关系 概念 说明 Gradle 安装在系统上的构建工具，命令是 gradle（例如 brew install gradle、SDKMAN） Gradle Wrapper 项目自带的一层「启动器」，命令是 ./gradlew（Windows 用 gradlew.bat） 关系 gradlew 不负责实现编译逻辑；它只负责下载并启动项目指定版本的 Gradle，再把 test、build 等任务交给真正的 Gradle 执行 一句话：Gradle 是引擎，gradlew 是带版本号的点火钥匙。 日常开发、CI 里应优先用 ./gradlew，而不是裸 gradle。这样所有人、每台机器用的是 gradle-wrapper.properties 里锁定的同一版本，避免「我这能编、你那报错」。 Wrapper 相关文件 这些文件应提交到 Git（官方建议）： 路径 作用 gradlew Unix/macOS 启动脚本 gradlew.bat Windows 启动脚本 gradle/wrapper/gradle-wrapper.jar 小 bootstrap 程序，负责下载真正的 Gradle 发行包 gradle/wrapper/gradle-wrapper.properties 锁定 Gradle 版本，核心是 distributionUrl distributionUrl 示例： ...