maven中配置 pom时,有时配置添加一个 jar却会自动导入多个 jar包,往往这些自动导入的 jar包会与我们项目中已存在的 jar包重复,从而导致冲突.由于这些 jar包不是我们自己配置的,所以遇到这种问题往往感觉一头雾水,下面记录一下开发情况中遇到的这类问题. 由于添加一个功能需要在项目中导入如下一个jar包 <dependency> <groupId>commons-httpclient</groupId> <artifactId>commons

使用Maven对JAVA程序打包-带主类.带依赖 http://blog.csdn.net/strongyoung88/article/details/54097830

作者:chenzhou123520 出处:http://chenzhou123520.iteye.com/blog/1706242 使用 maven 插件 maven-shade-plugin 对 java 工程及其全部依赖 jar 进行打包 博客分类: Maven Java maven-shade-pluginmaven-assembly-pluginmavenjar打包 现在基本上都是采用 maven 来进行开发管理,我有一个需求是需要把通过 maven 管理的 java 工程打成可执行的

本文将记录Maven工程中依赖解析机制,内容包括: Maven依赖基本结构 从仓库解析依赖的机制 依赖传递性解析实例 1. Maven依赖基本结构 上篇文章记录了Maven依赖的聚合与继承,POM中依赖的声明通过dependency进行定义,并且通过groupId.artifactId及version三项定位Maven库中的唯一依赖.除了这三项外,还有其他属性进行限制,如下: <dependencies> <dependency> <groupId>...</gr

为什么会出现依赖冲突 首先要说明Maven的依赖管理,具体的可以参考这边 Maven学习——依赖管理 这篇文章,maven在依赖冲管理中有一下几个原则. 依赖是使用Maven坐标来定位的,而Maven坐标主要由GAV(groupId, artifactId, version)构成.如果两个相同的依赖包,如果groupId, artifactId, version不同,那么maven也认为这两个是不同的. 依赖会传递,A依赖了B,B依赖了C,那么A的依赖中就会出现B和C. Maven对同一个gro

相同依赖级别,先加入的先依赖不同依赖级别,级别短的先依赖 version-->SNAPSHOTxxx-里程碑-->SNAPSHOT,alpha,beta,Release(RC),GA()svn版本控制cms0.0.1-SNAPSHOT-->cms0.0.1-Release-->cms1.0.1-SNAPSHOT -->cms0.1.1-SNAPSHOT-->cms1.0.1-RELEASE -->cms0.1.1-release 1. 依赖配置    依赖可以声明

背景 昨天帮一位同事排查了一个依赖冲突的问题.问题的现象就是在IntelliJ IDEA运行项目正常,但是打包(Maven assembly jar)之后传到服务器运行失败,报错:Caused by: java.lang.NoSuchFieldError: INSTANCE. 后来定位到某个类存在多个版本,其中一个版本是没有INSTANCE的.进一步发现项目所依赖的其他module,都是以assembly jar的形式install到本地仓库的,最终通过修改pom文件,对所依赖的module重新

说maven依赖冲突之前需要先说说maven的 依赖传递. 依赖传递 当前项目引入了一个依赖,该依赖的依赖也会被引入项目.更加准确的说法是,maven会解析直接依赖的POM,将那些必要的间接依赖,以传递依赖的形式引入到当前项目中. 为什么说是'必要的间接依赖'呢?这是因为不是所有的间接依赖都会被引入的.这还得说说maven的 依赖范围. 依赖范围 maven引入依赖,并不是把jar包拷贝到项目中来,而是把jar包下载到本地仓库,然后通过制定classpath来在项目中引入具体的jar包.mave

对于 Java 开发工程师来说,Maven 是依赖管理和代码构建的标准.遵循「约定大于配置」理念.Maven 是 Java 开发工程师日常使用的工具,本篇文章简要介绍一下 Maven 的依赖树解析. 依赖树结构 在 pom.xml 的 dependencies 中声明依赖包后,Maven 将直接引入依赖,并通过解析直接依赖的 pom.xml 将传递性依赖导入到当前项目,最终形成一个树状的依赖结构. 原则:深度优先遍历依赖,并缓存节点剪枝.比如下图: A→B→D→E/F A→C→D 在第二步A→C

一.前言 什么是依赖冲突 依赖冲突是指项目依赖的某一个jar包,有多个不同的版本,因而造成了包版本冲突. 依赖冲突的原因 我们在maven项目的pom中 一般会引用许许多多的dependency.例如,项目A有这样的依赖关系: A -> C -> X(1.0) B -> D -> X(2.0) X是A的传递性依赖,但是两条依赖路径上有两个版本的X,那么哪个X会被Maven解析使用呢? 两个版本都被解析显然是不对的,因为那会造成依赖重复,因此必须选择一个. 至于怎么选肯定有它的规则(

问题说明: 用maven构建了一个项目,目录结构如下: appassemblerd的配置: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>appassembler-maven-plugin</artifactId> <version>2.0.0</version> <configuration> <!-- 生成linux, window

1:前言 做软件开发这几年遇到了许多的问题,也总结了一些问题的解决之道,之后慢慢的再遇到的都是一些重复性的问题了,当然,还有一些自己没有完全弄明白的问题.如果做的事情是重复的,遇到重复性问题的概率也就会比较多了,如果是在一个新的领域里玩,遇到的问题又都是新的,自己从来没有见过的,但是问题的解决思路基本是类似的.下面这个问题,我觉得值得一记,因为以后还会再遇到类似的,我希望自己能很快的将其解决掉. 2:报错信息 如下是更新项目后,启动项目时抛出的部分错误信息. 十二月 14, 2016 7:52:

一.maven 依赖传递规则 举个例子,比如A依赖B,B依赖C,那么A也是依赖C的.A是对B的直接依赖,A对C是传递依赖 ①.最短路劲原则 如,路劲一:A依赖B,B依赖C,C依赖D(1.0.0): 路劲二:A依赖E,E依赖D(2.0.0), 此时A间接依赖D版本是2.0.0! ②.最先定义原则 如,路劲一:A依赖B,B依赖C(1.0.0): 路劲二:A依赖E,E依赖C(2.0.0), 此时A间接依赖C版本是1.0.0! 题外话,如果想精确的控制依赖包版本,可以使用依赖的排除功能——>exclus

前言 我们在项目开发中经常会将一些通用的类.方法等内容进行打包,打造成我们自己的开发工具包,作为各个项目的依赖来使用. 一般的做法是将项目导出成Jar包,然后在其它项目中将其导入,看起来很轻松,但是存在一个问题,如果你修改了Jar包的内容,岂不是要每个项目都重新导入,这显然是一种很不智能的做法. 那我们要怎样避免这种"牵一发而动全身"的效果呢?这里给大家介绍一种灵活的解决方法. 解决方法 自定义Maven依赖 Maven是一个项目管理工具,其中一个重要的组成部分就是依赖管理系统,用来解

之前通过学习了解,maven集成到eclipse中的如何创建项目,以及maven命令插件在eclipse中安装后的用法.那么接下来我们将会学习一些maven在项目中的一些特性,及如何使用. Maven依赖特性 基于之前我们创建的maven-web-project01项目,接下来学习如何通过maven引入一个新包,比如:我需要使用mysql的驱动包,此时在baidu中搜索maven repository,可以找到官网:https://mvnrepository.com/,在搜索栏中输入mysql

hessian结合spring的demo         hessian的maven依赖: <!-- hessian --> <dependency>         <groupId>com.caucho</groupId>         <artifactId>hessian</artifactId>         <version>4.0.7</version> </dependency>

1.确定打包对象:dubbo-admin 2.进入打包对象目录,复制目录路径(D:\H\dubbox-master\dubbo-admin). 可以看到该对象为典型的maven目录,此时没有“target”文件夹 3.通过命令行进入该目录下,并键入如下命令(-Dmaven.skip.test=true代表跳过测试直接打包,避免因环境检查不合要求而影响打包) mvn package -Dmaven.skip.test=true 4.回车执行完毕,当出现如图“BUILD SUCCESS”标志时,打包

.Maven因为执行一系列编译.测试和部署运行等操作,在不同的操作下使用的classpath不同,依赖范围就是用来控制依赖与三种 classpath(编译classpath.测试classpath.运行classpath)的关系. Maven有以下几种依赖范围: compile:编译依赖范围(默认),使用此依赖范围对于编译.测试.运行三种 classpath 都有效,即在编译.测试和运行的时候都要使用该依赖jar包: test:测试依赖范围,从字面意思就可以知道此依赖范围只能用于测试classp

Maven依赖中的scope详解 项目中用了<scope>test</scope>在eclipse里面用maven install可以编译成功,到服务器上用命令执行报VM crash错误,原因是test代码提交上去了,但没有对应的junit包导致的 解决办法:1.服务器上编译的时候排除掉test代码.2.把<scope>test</scope>改成<scope>compile</scope> <dependency> &l

maven依赖管理 1.依赖范围   (依赖相当于java中的import  是否需要导入别的jar包) 使用控制依赖与三种classpath(编译期,测试时期,运行时期)的关系 complie   在编译,测试,运行时期,a项目在编译期依赖b,并且在测试和运行时期也依赖b项目, (默认值)             会打jar包或者war包 test    只在测试时有效,    a项目只在测试时依赖b项目,   不会打jwar包 provided  在编译和测试是有效,在运行时不会打jar或w

案例分析 让我们看一个案例研究,以了解它是如何工作的.假设你想使用 Log4j 作为项目的日志.这里你要做什么? 1.在传统方式 访问 http://logging.apache.org/log4j/ 下载 Log4 j的 jar 库 复制 jar 到项目类路径 手动将其包含到项目的依赖 所有的管理需要一切由自己做 如果有 Log4j 版本升级,则需要重复上述步骤一次. 2. 在Maven的方式 你需要知道 log4j 的 Maven 坐标,例如: <groupId>log4j</gro