idea解决maven的依赖包冲突，包的版本不一样怎么办

要解决这个问题，首先就是要查看pomxml显式和隐式的依赖类包，然后通过这个类包树找出我们不想要的依赖类包，手工将其排除在外就可以了。
打开pomxml，通过右键菜单：maven->show dependency 打开分析的图形化页面，如下所示：
通过这个依赖树，我们还可以看到哪些包被间接载入了，找到需要排除的包，右键选着exclude即解决这个间接依赖。

用 maven2 ，pomxml中设置了依赖，会帮你下载所有依赖的jar到 M2_REPO 指向的目录
你的采纳是我前进的动力，还有不懂的地方，请继续“追问”。
如你还有别的问题，可另外向我求助；答题不易，互相理解，互相帮助。

回答：

目前项目组在开发一个项目，由多个子模块构成，构建工具是maven，版本控制工具是svn。本文想对如何结合使用maven和svn提出一点初步的想法

一、只有svn的情况 
1、首先考虑没有maven的情况。这样的话，项目组每个开发人员，都需要在本地check out所有的源码。
2、每次提交之前，需要先更新周边工程的代码。由于工程之间是依赖的，所以很可能需要把所有的代码都更新一遍。在项目依赖混乱的情况下，就更麻烦 ，等于说，项目组成员之间的协作，是以SVN为中心的 
这种做法的缺点在于： 
1、开发人员本地需要有所有的代码，编译速度很慢 
2、如果是别人负责的模块出错，会影响自己的开发。如果项目比较大的话，别人负责的模块的问题，自己实际上是解决不了的
这种做法的优点在于： 
1、提交之前做一次全量更新，相当于在本地做了一次全量编译，提交到SVN上基本可以保证不会出现编译错误。我称之为“悲观提交”，类似于数据库里“悲观锁” 
2、由于本地有所有代码，所以本地构建比较不容易出错 
二、引入maven的情况 
1、maven的主要作用之一，就是对模块化开发的支持
2、开发人员A机器上可以只有工程A，开发人员B机器上只有工程B，其中工程B依赖工程A 
3、只要工程A已经deploy到了远程仓库（私服），那么工程B就可以在本地构建，不需要有工程A的代码。也就是说，每个开发人员本地，都只需要check out自己负责的工程
这种做法的优点在于： 
1、每个人只有自己负责的代码，本地构建的速度快 
2、如果其他的模块构建出错，对自己的模块不容易造成影响 
3、职责划分清晰 
这种做法的缺点是： 
1、高层模块的构建，依赖于低层的模块。由于开发人员B本地只有工程B的代码，如果工程A还没有deploy到远程仓库，则工程B就无法进行本地构建 
2、提交到SVN后，有可能造成SVN上的全量编译失败。比如A删除了一个方法，并提交到svn，但是没有deploy。那么B就会基于A模块旧的构件来进行本地构建，成功后也提交了代码。这样的话，在svn上编译就无法通过

1 项目组在开发一个项目，由多个子模块构成，构建工具是maven，版本控制工具是svn。
2maven： 是对模块化开发的支持 ，也就是说，每个开发人员本地，都只需要check out自己负责的工程。
3svn：首先考虑没有maven的情况。这样的话，项目组每个开发人员，都需要在本地check out所有的源码。 每次提交之前，需要先更新周边工程的代码。由于工程之间是依赖的，所以很可能需要把所有的代码都更新一遍

21 使用Intellij Idea创建gradle项目
首先在Idea中启用Gradle支持：Settings->Plugins: Gradle
然后创建一个gradle项目或模块，会发现目录结构和maven的很像，其中buildgradle是gradle的配置文件，类似于maven中pomxml文件，以下是buildgradle的简单示例：
apply plugin: 'java'
group = 'orgyousharp'
version = '10-SNAPSHOT'
sourceCompatibility = 17
targetCompatibility = 17
repositories {
mavenCentral()
maven { url ">参考书籍(推荐大家购买实体书):《Maven实战》(国内首本Maven著作)(Maven的安装、配置及使用入门)1概述Maven是一个构建工具,服务与构建使用Maven配置好项目后,输入简单的命令,如:mvn clean install,Maven会帮我们处理那些繁琐的任务Maven是跨平台的Maven最大化的消除了构建的重复Maven可以帮助我们标准化构建过程所有的项目都是简单一致的,简化了学习成本总之,Maven作为一个构建工具,不仅帮我们自动化构建,还能抽象构建过程,提供构建任务实现他跨平台,对外提供一致的 *** 作接口,这一切足以使他成为优秀的,流行的构建工具但是Maven不仅是构建工具,他还是一个依赖管理工具和项目信息管理工具他还提供了中央仓库,能帮我们自动下载构件使用Maven还能享受一个额外的好处，即Maven对于项目目录结构、测试用例命名方式等内容都有既定的规则，只要遵循了这些成熟的规则，用户在项目间切换的时候就免去了额外的学习成本，可以说是约定优于配置（Convention Over Configuration）。2对比,Maven,IDE,Mark,AntaIDE:基本上所有的主流IDE都集成了Maven,我们可以在IDE中方便的运行Mave执行构建IDE依赖大量的手工 *** 作。编译、测试、代码生成等工作都是相互独立的，很难一键完成所有工作。手工劳动往往意味着低效，意味着容易出错很难在项目中统一所有的IDE配置，每个人都有自己的喜好。也正是由于这个原因，一个在机器A上可以成功运行的任务，到了机器B的IDE中可能就会失败。所以,要合理使用IDE,不过多依赖Maven是专家bMake也许是最早的构建工具，具体不详,没用过,可以不了解Make的强大之处在于它可以利用所有系统的本地命令，尤其是UNIX/Linux系统，丰富的功能、强大的命令能够帮助Make快速高效地完成任务。但是，Make将自己和 *** 作系统绑定在一起了。也就是说，使用Make，就不能实现（至少很难）跨平台的构建，这对于Java来说是非常不友好的。此外，Makefile的语法也成问题，很多人抱怨Make构建失败的原因往往是一个难以发现的空格或Tab使用错误。cAnt是意指“另一个整洁的工具”（Another Neat Tool），它最早用来构建著名的Tomcat，其作者James Duncan Davidson创作它的动机就是因为受不了Makefile的语法格式。我们可以将Ant看成是一个Java版本的Make，也正因为使用了Java，Ant是跨平台的。此外，Ant使用XML定义构建脚本，相对于Makefile来说，这也更加友好。和Make一样，Ant也都是过程式的，开发者显式地指定每一个目标，以及完成该目标所需要执行的任务。针对每一个项目，开发者都需要重新编写这一过程，这里其实隐含着很大的重复。Maven是声明式的，项目构建过程和过程各个阶段所需的工作都由插件实现，并且大部分插件都是现成的，开发者只需要声明项目的基本元素，Maven就执行内置的、完整的构建过程。这在很大程度上消除了重复。Ant是没有依赖管理的，所以很长一段时间Ant用户都不得不手工管理依赖，这是一个令人头疼的问题。幸运的是，Ant用户现在可以借助Ivy管理依赖。而对于Maven用户来说，依赖管理是理所当然的，Maven不仅内置了依赖管理，更有一个可能拥有全世界最多Java开源软件包的中央仓库，Maven用户无须进行任何配置就可以直接享用。3Maven与极限编程极限编程（XP）是近些年在软件行业红得发紫的敏捷开发方法，它强调拥抱变化。简单。Maven暴露了一组一致、简洁的 *** 作接口，能帮助团队成员从原来的高度自定义的、复杂的构建系统中解脱出来，使用Maven现有的成熟的、稳定的组件也能简化构建系统的复杂度。交流与反馈。与版本控制系统结合后，所有人都能执行最新的构建并快速得到反馈。此外，自动生成的项目报告也能帮助成员了解项目的状态，促进团队的交流。Maven几乎能够很好地支持任何软件开发方法。例如，在传统的瀑布模型开发中，项目依次要经历需求开发、分析、设计、编码、测试和集成发布阶段。从设计和编码阶段开始，就可以使用Maven来建立项目的构建系统。在设计阶段，也完全可以针对设计开发测试用例，然后再编写代码来满足这些测试用例。然而，有了自动化构建系统，我们可以节省很多手动的测试时间。此外，尽早地使用构建系统集成团队的代码，对项目也是百利而无一害。最后，Maven还能帮助我们快速地发布项目。

在Maven中，依赖的管理和使用主要分为两种方式：本地仓库和远程仓库。本地仓库是指存储在本地计算机上的Maven仓库，而远程仓库则是指存储在网络上的Maven仓库。在开发环境中，我们通常会将依赖存储在本地仓库中，以提高构建速度。但是，在生产环境中，我们需要将依赖从本地仓库移到远程仓库中。
以下是在生产环境中使用Maven依赖的步骤：
将本地仓库中的依赖上传到远程仓库中。可以使用Maven命令或者通过Maven客户端（如Nexus）上传依赖。
在pomxml文件中更改依赖的配置。将原来指向本地仓库的依赖改为指向远程仓库中的依赖。
例如，将以下依赖配置：
plaintext
Copy code
<dependency>
<groupId>comexample</groupId>
<artifactId>example</artifactId>
<version>100</version>
</dependency>
改为：
plaintext
Copy code
<dependency>
<groupId>comexample</groupId>
<artifactId>example</artifactId>
<version>100</version>
<scope>provided</scope>
<type>pom</type>
<exclusions>
<exclusion>
<groupId></groupId>
<artifactId></artifactId>
</exclusion>
</exclusions>
<repositories>
<repository>
<id>nexus</id>
<url>>