起初是新加了个模块,启动前编译时error,提示找不到依赖模块的类,但java文件上是没有报错的. 后经过排查,发现是循环依赖导致的此问题. 如图,弹出框中有循环依赖的模块会显示红色,右键Open Module Settings,删除.当然,我当时是无法删除的,pom中也没有发现循环的依赖,最后在有问题的模块里的.iml文件中发现了问题! 删掉,重新编译!解决!

环境:win7 64位,myeclipse10.6,eclipse4.5,都配置了svn插件 问题描述:1.工程模块化之后都是通过pom配置model来关联的,svn提交之后,通过myeclipse的svn‘检出为项目’,依赖的子工程变成了文件夹:原先的maven项目jar都不对了.删除本地仓库重新编译,原先项目ok 2.以为是myeclipse的问题,通过eclipse同样步骤,出现同样问题 解决:1.单独安装svn,把项目先检出,然后在用eclipse把项目import进去,选择‘已存在的m

转自:https://blog.csdn.net/leolu007/article/details/53079875 添加新随笔很​多​时​候​随​着​项​目​的​膨​胀​,模​块​会​越​来​越​多​,如​果​设​计​上​ 稍​有​不​慎​就​会​出​现​模​块​之​间​相​互​依​赖​的​情​况​.​这​对​于​使​用​Maven的​用​户​是​比​较​痛​苦​的​,因​为​出​现​模​块​之​间​相​互​依​赖​的​话​在​构​建​的​时​候​就​会​失​败​,Maven通​常​要​先​编

1.前言 在大型企业项目中,系统架构复杂多变,一个项目根本无法支撑起所有业务.为了提高项目扩展性.灵活性.重用性,封装性,将项目分为多个Module是非常必要的. 这里就不说IDEA如何安装了,安装好IDEA后需要修改maven配置settings.xml,添加阿里镜像地址,提高maven下载依赖包速度.打开文件D:\Program Files\JetBrains\IntelliJ IDEA 2019.1\plugins\maven\lib\maven3\conf\settings.xml,找到

若排版紊乱可查看我的个人博客原文地址 maven的依赖特性很多很杂,这里大概总结一下,maven的依赖特性主要是依赖范围和传递依赖,前者会影响后者,这篇文章会介绍传递依赖的传递原则,出现冲突传递依赖默认如何处理,我们自己可以怎么处理等内容 依赖范围 依赖范围会影响传递性依赖,同时也会影响项目构建任务中使用的classpath. Maven有以下6种依赖范围: compile 这是默认范围.如果没有指定,就会使用该依赖范围.编译依赖对项目所有的classpath都可用.此外,编译依赖会传递到依赖的

在maven的管理体系中,各个项目组成了一个复杂的关系网,但是每个项目都是平等的,是个没有贵贱高低,众生平等的世界,全球每个项目从理论上来说都可以相互依赖.就是说,你跟开发Spring的大牛们平起平坐,你的项目可以依赖Spring项目,Spring项目也可以依赖你的项目(虽然现实中不太会发生,你倒贴钱人家也不敢引用). 项目的依赖关系主要分为三种:依赖,继承,聚合 依赖关系 依赖关系是最常用的一种,就是你的项目需要依赖其他项目,比如Apache-common包,Spring包等等. <depen

什么是Maven 1 依赖的管理:仅仅通过jar包的几个属性,就能确定唯一的jar包,在指定的文件pom.xml中,只要写入这些依赖属性,就会自动下载并管理jar包. 2 项目的构建:内置很多的插件与生命周期,支持多种任务,比如校验.编译.测试.打包.部署.发布... 3 项目的知识管理:管理项目相关的其他内容,比如开发者信息,版本等等 官网:http://maven.apache.org/ Maven库:http://repo2.maven.org/maven2/ 中央仓库资源:http://

我们知道,maven的依赖关系是有传递性的.如:A-->B,B-->C.但有时候,项目A可能不是必需依赖C,因此需要在项目A中排除对A的依赖.在maven的依赖管理中,有两种方式可以对依赖关系进行,分别是可选依赖(Optional Dependencies)以及依赖排除(Dependency Exclusions). 一.可选依赖 当一个项目A依赖另一个项目B时,项目A可能很少一部分功能用到了项目B,此时就可以在A中配置对B的可选依赖.举例来说,一个类似hibernate的项目,它支持对mys

Maven的依赖构件包含一个依赖范围属性,这个属性描述的是三套classpath的控制,即编译.测试.运行. 举个例子Junit依赖只是在测试范围(classpath)使用,而在运行的时候不使用,还有Servlet api在编译的时候使用,在运行部署的时候不使用,因为大部分容器都已经提供该依赖支持. <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit<

前言 在国内编译Spark项目需要从Maven源下载很多依赖包,官方源在国内大环境下的下载速度大家都懂得,那个煎熬啊,简直是浪费生命. 如果你的下载速度很快,你现在就可以无视这篇文章了. 阿里云给国内开发者提供了一个非常的良心的服务:提供了一个国内Maven镜像,可以让我们拜托这种煎熬. 地址信息 阿里云的Maven也是基于nexus构建. 地址:http://maven.aliyun.com/ 仓库地址:http://maven.aliyun.com/nexus/content/groups/

1.Maven的依赖1.1 添加依赖1.2 依赖范围(sope)依赖范围与classpath的关系1.3 依赖的传递性1.2.1 依赖传递性的冲突问题1. 第一种情况2. 第二种情况1.2.2 通过exclusions元素排除不想要的传递性依赖1.2.3 依赖传递性冲突问题解决办法总结1.4 依赖版本的界限 1.Maven的依赖 Maven的依赖通过dependencis元素来配置依赖,这是Maven最强大的特性之一.它支持传递性依赖. 1.1 添加依赖 在Maven中需要使用在dependen

Maven组织项目进行编译.部署 Maven项目基本的结构说明如下: mazhi  // 控制所有荐的编译.部署.发布 mazhi-app-parent  // 项目的父项目,有一些公共的设置可以被子项目继承 mazhi-core  // 基础服务项目,例如公共类等 mazhi-xxx    其中mazhi和mazhi-app-parent是pom格式,而mazhi-core是jar格式,还可以是 war等格式. 我们以新建mazhi和mazhi-core项目为例说明一下. 新建Maven-pr

以下内容引用自https://ayayui.gitbooks.io/tutorialspoint-maven/content/book/maven_manage_dependencies.html: 一.前言 Maven的一个核心特性就是依赖管理.当我们涉及到多模块的项目(包含成百个模块或者子项目),管理依赖就变成一项困难的任务.Maven展示出了它对处理这种情形的高度控制. 二.可传递性依赖 一种相当常见的情况,当一个库,比如说A依赖于其他库B.假如,另外一个项目C想要使用A,那么项目也需要使

Maven外部依赖 正如大家所了解的那样,Maven确实使用 Maven 库的概念作依赖管理.但是,如果依赖是在远程存储库和中央存储库不提供那会怎么样? Maven 提供为使用外部依赖的概念,就是应用在这样的场景中的. 举一个例子,让我们在 Maven创建项目 这一章节中创建的项目做以下的修改. 添加 lib 文件夹到 src 文件夹 复制任何的 jar 到 lib 文件夹.这里使用的是 ldapjdk.jar,这是 LDAP 操作的辅助库. 现在我们的项目结构看起来应该类似下面这样: 在这里,

问题 maven传递依赖 解决方案   前段时间,开发中遇到一个关于maven依赖包的问题:由于业务需要,支付网关对账代码中的slf4j-api包需要更新,原包为1.5.8版本,需要更新到1.6.4版本.如下图:   本来应该是件很简单的事情,把pom.xml文件里的依赖项修改下就OK了嘛!可是,打开pom.xml文件才发现,dependency里根本没有slf4j的配置信息.那么,问题来了,这个jar包是怎么引进来的呢?研究了半天也没找到根源,由于还有其他工作,就没有继续研究,临时解决方案为:

Qestion /** * ClassInitializedOrder for : Java Classload Order Test * * @author <a href="mailto:magicianisaac@gmail.com">Isaac.Zhang | 若初</a> * @since 2019/7/20 */ // CASE 1 public class ClassInitializedOrder { private static boolean

现在,你也知道Maven做依赖管理使用Maven仓库的概念.但是,如果依赖是不提供任何远程存储库和中央存储库发生了什么? Maven提供为使用外部依赖的概念,应用在这样的场景. 举一个例子,让我们做以下修改项在目Maven创建项目 这一章节中创建. 添加lib文件夹到src文件夹 复制任何的jar到lib文件夹.我们使用ldapjdk.jar,这是LDAP操作的辅助库. 现在我们的项目结构看起来应该像下面的: 在这里,有自己的特定项目,这是很平常案例库,它可以包含jar文件可能无法在任何Mave

compile(编译范围) compile是默认的范围:如果没有提供一个范围,那该依赖的范围就是编译范 围.编译范围依赖在所有的classpath中可用,同时它们也会被打包. provided(已提供范围) provided依赖只有在当JDK或者一个容器已提供该依赖之后才使用.例如,如果 你开发了一个web应用,你可能在编译classpath中需要可用的Servlet API来编 译一个servlet,但是你不会想要在打包好的WAR中包含这个Servlet API:这个 Servlet API

在Maven中依赖的域有这几个:import.provided.runtime.compile.system.test 1compile 的范围 当依赖的scope为compile的时候,那么当前这个依赖的包,会在编译的时候将这个依赖加入进来,并且在打包(mvn package)的时候也会将这个依赖加入进去 意思就是:编译范围有效,在编译与打包时都会存储进去 2provided的范围 当依赖的scope为provided的时候,在编译和测试的时候有效,在执行(mvn package)进行打包成w

前面我们讲了maven项目中的最重要的文件:pom.xml 配置文件相关内容.介绍了pom 是如何定义项目,如何添加依赖的jar 包的等. 我们知道,在Maven的生命周期中,存在编译.测试.运行等过程,那么有些依赖只用于测试,比如junit:有些依赖编译用不到,只有运行的时候才能用到,比如mysql的驱动包在编译期就用不到(编译期用的是JDBC接口),而是在运行时用到的:还有些依赖,编译期要用到,而运行期不需要提供,因为有些容器已经提供了,比如servlet-api在tomcat中已经提供了,