一个中大型的 Java 项目往往包含若干 JAR 包,这些 JAR 包有着不同的版本号.如果这些 JAR 包单独发布,然后直接通过版本号引用相应的 JAR 包,不同版本的兼容性维护将变得十分麻烦.为了解决这个问题,可以让一个特殊的模块引用这些 JAR 包,将版本号定义在这个模块中,模块中的 JAR 都是兼容的,对外发布时只发布这个特殊模块.这个特殊模块就是 BOM(Bill Of Materials). 著名的 Spring Boot 就使用了这种方式来管理版本号,这个模块就是 spring-b

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

A >  B  >  C A依赖于B,B依赖于C,如果A想间接依赖C,那么B和C之间的依赖范围必须是compile,不然A依赖不了C 但是有点麻烦,因为每次A想依赖于C都要确认B和C之间的依赖范围是否是compile,否则A依赖不了C,每次确认都会费时间 而且有些依赖的默认范围不是compile,如果修改默认的依赖范围可能导致冲突,比如servlet-api.jar的默认依赖范围是provided,如果修改servlet的默认依赖范围为compile,那么间接依赖serlvet的项目在运行时会

在使用maven过程中,我们在开发阶段经常性的会有很多公共库处于不稳定状态,随时需要修改并发布,可能一天就要发布一次,遇到bug时,甚至一天要发布N次.我们知道,maven的依赖管理是基于版本管理的,对于发布状态的artifact,如果版本号相同,即使我们内部的镜像服务器上的组件比本地新,maven也不会主动下载的.如果我们在开发阶段都是基于正式发布版本来做依赖管理,那么遇到这个问题,就需要升级组件的版本号,可这样就明显不符合要求和实际情况了.但是,如果是基于快照版本,那么问题就自热而然的解决了

1.登录http://maven.apache.org/download.cgi 2.拉倒最下面,点击 archives 3.可以看到maven个版本,找自己需要的下载

在看别人的源码的过程中,会遇到这种情况,就是很多jar包没有指定版本,却能够下载下来. 在后来的研究中发现,有这样一个配置. <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>.RELEASE</version> </parent> 那

<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Dalston.SR3</version> <type>pom</typ

<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&

女朋友他们项目用了 spring-boot,以 spring-boot-parent 作为 parent: <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.9</version> </parent> 女朋友最近想用 elast

项目执行Maven clean后出现WARNING提示.报如信息如下,根据报错信息 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 104, column 12 猜测是maven-compiler-plugin的版本信息缺失问题 [INFO] Scanning for projects... [WARNING] [WARNING] Some p

情景:当使用Spring下的多个包时,为了方便版本号的统一管理,避免出现因不同版本号造成的错误,必须更改为统一的版本号,但是当项目过多时手动修改不方便,因此引入此标签可以方便进行统一的修改. pom.xml修改如下: <properties> <!-- 统一声明版本号 --> <quinntian.version>4.0.1.RELEASE</quinntian.version> </properties> <dependency>

一种是配置 pom.xml,一种是配置 settings.xml. 方式一:settings.xml 配置 打开 %maven%/conf/settings.xml 文件并编辑它(%maven% 表示 maven 的根目录) : <profiles> <profile> <id>development</id> <activation> <jdk>1.7</jdk> <activeByDefault>true&

org.springframework 3.0.x对应org.hibernate4.0.x版本 org.springframework 3.2.x对应org.hibernate4.2.x版本 org.springframework 4.0.x对应org.hibernate4.3.x版本 org.springframework 4.1.x对应org.hibernate5.0.x版本 org.springframework 4.3.x对应org.hibernate5.1.x版本 hibernate

使用maven的时候,默认会使用1.5版本的JDK,并且也是编译成1.5的,我的电脑里面用的JDK是1.7的,1.8也出来了,没理由还用1.5的吧!所以我手动改成了1.7,郁闷的是,每次 maven-update project 的时候,又变成1.5的了   查阅了相关资料后,发现了修改的方法,打开maven安装目录下的 maven-->conf   修改settings.xml,找到profiles节点,在里面添加 <profile> <id>jdk-1.7</id&

Maven中建立的依赖管理方式基本已成为Java语言依赖管理的事实标准,Maven的替代者Gradle也基本沿用了Maven的依赖管理机制.在Maven依赖管理中,唯一标识一个依赖项是由该依赖项的三个属性构成的,分别是groupId.artifactId以及version.这三个属性可以唯一确定一个组件(Jar包或者War包). 其实在Nexus仓库中,一个仓库一般分为public(Release)仓和SNAPSHOT仓,前者存放正式版本,后者存放快照版本.如果在项目配置文件中(无论是build

项目中代码红线报版本不支持xx语法,只需要将java版本设置为当前机器使用的java版本即可 这里我使用的是idea自带的maven,如果是自己安装的maven需要在 home directory 处指定maven路径, 如果是自己安装的maven,也需要在下面两处指定maven的配置文件和仓库路径(必须确保修改过settings.xml的配置  必须确保配置文件和仓库都确实存在,否则会出现pom.xml报红线  maven无法导入jar包的问题) 如果是用idea自己的maven,那就选择好需

问题描述 我有两个项目:父项目:A,子项目:B 在A /pom.xml中: <groupId>com.dummy.bla</groupId> <artifactId>parent</artifactId> <version>0.1-SNAPSHOT</version> <packaging>pom</packaging> 在B /pom.xml中,我有: <parent> <groupId&g

maven中构件和项目都有自己的版本,其中分为稳定的发布版本和不稳定的快照版本. 1.0.0.1.3-alpha-4和2.0就是稳定版本,而2.1-SNAPSHOT和2.1-20091214.221414-13就是不稳定的快照版本. maven的快照版本机制发布到私服中,maven会自动为构件打上时间戳,20091214.221414代表的就是2009年12月14号22点14分14秒,而13就是说明打的第13次快照.有了时间戳,maven能随时找到仓库中该构件的最新版本.

博客:maven依赖jar包时版本冲突的解决

Bug的身世之谜 今天又分享一个问题解决的故事.请看下图框起来的错误,明显就是找不到这个class嘛! 下面我们按照正常人的思路去排查这个问题,既然找不到class那就先看这个依赖的jar包有没有,如果没有那就是铁证如山. 但是事与愿违啊,编译后的lib目录下真的有这个包o****rder-api-2.0-SNAPSHOT.jar 还是不相信,于是将order-api-2.0-SNAPSHOT.jar解压了,看看里面到底有没有我们需要的class,真的有,此处心情沉重. 一般人到这里就会懵圈了,

1查询官网地址,提供了详细的各个版本的jar依赖版本信息 https://www.cloudera.com/documentation/enterprise/release-notes/topics/cdh_vd_cdh5_maven_repo_516x.html