smproxy-1.0.1.jar maven依赖镜像在哪里能下载到？哪位开发指导一下

在开发过程中，有时候会遇到需要将本地的 JAR 包安装到 Maven 仓库的情况，比如使用一些没有在公共 Maven 仓库中的第三方库。下面为你介绍几种不同场景下将 JAR 包安装到 Maven 仓库的方法。基础命令安装可以使用 mvn install:install-file 命令把 JAR 包安装到本地 Maven 仓库，以下是具体命令示例：mvn install:install-file -Dfile=path/to/your.jar -DgroupId=com.yourcompany -DartifactId=your-artifact -Dversion=1.0 -Dpackaging=jar参数说明：-Dfile：指定 JAR 包的本地路径。-DgroupId：定义 JAR 包的组织或公司名称，一般使用反向域名。-DartifactId：代表项目或模块的名称。-Dversion：表示 JAR 包的版本号。-Dpackaging：指定打包类型，通常为 jar。示例假设你有一个名为 example.jar 的 JAR 包，需要将其安装到本地 Maven 仓库，对应的 groupId 为 com.example，artifactId 为 example-library，版本号为 1.0，可以使用以下命令：mvn install:install-file -Dfile=example.jar -DgroupId=com.example -DartifactId=example-library -Dversion=1.0 -Dpackaging=jar运行上述命令之后，Maven 就会把 JAR 包安装到本地仓库对应的目录下。在项目的 pom.xml 里引用已安装的 JAR 包当 JAR 包安装到本地 Maven 仓库之后，你可以在项目的 pom.xml 文件里引用该 JAR 包，示例如下：xml<dependencies> <dependency> <groupId>com.example</groupId> <artifactId>example-library</artifactId> <version>1.0</version> </dependency> </dependencies>安装带有依赖的 JAR 包要是 JAR 包有依赖项，你需要确保所有依赖项也被正确安装到本地 Maven 仓库。可以通过以下步骤操作：把依赖的 JAR 包也安装到本地 Maven 仓库，使用 mvn install:install-file 命令逐个安装。在 pom.xml 文件里添加所有依赖项的声明。安装带有 POM 文件的 JAR 包若 JAR 包附带了 POM 文件，可使用以下命令安装：mvn install:install-file -Dfile=path/to/your.jar -DpomFile=path/to/your.pom 此命令会依据 POM 文件里的配置安装 JAR 包及其依赖项。通过上述步骤，你就可以把 JAR 包安装到 Maven 仓库，并且在项目里引用它。

在 Maven 的 settings.xml 文件中，你可以配置多个镜像和仓库来实现你的需求。以下是一个示例配置，展示了如何从局域网内部服务器开始查找依赖，如果没找到再从阿里云仓库查找，如果仍然没找到，则回退到 Maven 官方仓库。<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <!-- 配置本地仓库位置（可选） --> <localRepository>/path/to/local/repo</localRepository> <mirrors> <!-- 配置局域网内部仓库 --> <mirror> <id>internal-repo</id> <mirrorOf>*</mirrorOf> <url>http://your-internal-repo-url/repository/maven-public/</url> <blocked>false</blocked> </mirror> <!-- 配置阿里云仓库 --> <mirror> <id>aliyun-repo</id> <mirrorOf>external:*</mirrorOf> <url>https://maven.aliyun.com/repository/public</url> <blocked>false</blocked> </mirror> <!-- 注意：官方仓库不需要配置为镜像，因为它是默认行为 --> </mirrors> <profiles> <!-- 你可以在这里配置一些 profiles，不过对于这个问题来说不是必须的 --> </profiles> <activeProfiles> <!-- 同样，对于这个问题来说，不需要激活特定的 profile --> </activeProfiles> <!-- 关键部分：配置仓库顺序 --> <servers> <!-- 配置认证信息（如果需要的话） --> <!-- 局域网内部仓库认证信息 --> <server> <id>internal-repo</id> <username>your-internal-repo-username</username> <password>your-internal-repo-password</password> </server> <!-- 阿里云仓库认证信息（如果需要的话） --> <!-- <server> <id>aliyun-repo</id> <username>your-aliyun-repo-username</username> <password>your-aliyun-repo-password</password> </server> --> </servers> <!-- 注意：这里没有显式配置官方仓库，因为 Maven 默认会从官方仓库下载 --> </settings> 解释：镜像配置 (<mirrors>)：internal-repo：首先尝试从局域网内部仓库下载依赖。aliyun-repo：如果局域网内部仓库找不到依赖，Maven 会尝试从阿里云仓库下载。这里使用了 mirrorOf 的 external:* 匹配模式，意味着它只替代官方仓库和外部仓库。服务器认证 (<servers>)：配置了局域网内部仓库的认证信息。如果阿里云仓库需要认证，也可以在这里添加相应的配置。默认行为：Maven 默认会从 Maven 中央仓库（官方仓库）下载依赖。由于我们配置了 mirrorOf=* 的镜像，它会优先查找这些镜像。如果镜像中都没有找到，Maven 会回退到官方仓库。注意事项：mirrorOf 属性用于指定哪些仓库（或所有仓库）被镜像替代。* 表示所有仓库，external:* 表示除了本地仓库以外的所有仓库。确保你配置的 URL 和认证信息是有效的。这个配置假设你的局域网内部仓库和阿里云仓库已经正确设置，并且可以访问。

maven 访问返回 418

https://mirrors.huaweicloud.com/repository/maven/huaweicloudsdk/下的相关文件无法正常下载了。提示：418您的请求疑似攻击行为？？？？？

一、依赖冲突产生的原因 调用的某个A包依赖于B包，B又依赖于C 和D 但是C依赖于E的1.0版本，D依赖于E的2.0版本  1.0跟2.0冲突了。 常见解决办法：直接使用2.0版本，删除1.0的依赖 原因：正常开源是向下依赖的，也就是说新版本都是包含老版本内容的。所以一般都可以直接使用2.0，这样1.0的依赖就需要我们手工把他干掉，这样就不冲突啦 二、CDM命令行： 2.1查看依赖树 进入到项目路径，输入依赖树命令 E:\Develop\eclipse\workspace\oa-organ>mvn dependency:tree 返回如下： ... Downloaded from aliyun: http://maven.aliyun.com/nexus/content/groups/public/org/apache/maven/shared/maven-invoker/2.0.11/maven-invoker-2.0.11.jar (29 kB at 12 kB/s) Downloaded from aliyun: http://maven.aliyun.com/nexus/content/groups/public/commons-lang/commons-lang/2.6/commons-lang-2.6.jar (284 kB at 115 kB/s) [INFO] com.xxxx.oa:oa-organ:jar:1.0.0-SNAPSHOT [INFO] +- org.springframework:spring-core:jar:3.2.8.RELEASE:compile [INFO] |  \- commons-logging:commons-logging:jar:1.1.3:compile [INFO] +- org.springframework:spring-webmvc:jar:3.2.8.RELEASE:compile [INFO] |  +- org.springframework:spring-beans:jar:3.2.8.RELEASE:compile [INFO] |  \- org.springframework:spring-expression:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-context:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-context-support:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-aop:jar:3.2.8.RELEASE:compile [INFO] |  \- aopalliance:aopalliance:jar:1.0:compile [INFO] +- org.springframework:spring-aspects:jar:3.2.8.RELEASE:compile [INFO] |  \- org.aspectj:aspectjweaver:jar:1.7.4:compile [INFO] +- org.springframework:spring-tx:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-jdbc:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-web:jar:3.2.8.RELEASE:compile [INFO] +- junit:junit:jar:4.13.2:test [INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test [INFO] +- org.springframework:spring-test:jar:3.2.8.RELEASE:test [INFO] +- log4j:log4j:jar:1.2.12:compile [INFO] +- org.slf4j:slf4j-api:jar:1.6.6:compile [INFO] +- org.slf4j:slf4j-log4j12:jar:1.6.6:compile [INFO] +- org.mybatis:mybatis:jar:3.2.1:compile [INFO] +- org.mybatis:mybatis-spring:jar:1.2.0:compile [INFO] \- mysql:mysql-connector-java:jar:5.1.47:compile [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time:  39.332 s [INFO] Finished at: 2021-11-27T23:06:45+08:00 [INFO] ------------------------------------------------------------------------  2.2 修改项目中的pom.xml文件 在原有的依赖dependency中增加如下 下面<exclusions></exclusions>中间这一段是新增的  <!-- spring依赖 -->           <dependency>               <groupId>org.springframework</groupId>               <artifactId>spring-core</artifactId>               <version>3.2.8.RELEASE</version>                   <exclusions>                     <exclusion>                       <groupId>commons-logging</groupId>                       <artifactId>commons-logging</artifactId>                     </exclusion>                 </exclusions>         </dependency>   2.3再次查看依赖树  E:\Develop\eclipse\workspace\oa-organ>mvn dependency:tree 返回如下 [INFO] Scanning for projects... [INFO] [INFO] ------------------------< com.xxxx.oa:oa-organ >------------------------ [INFO] Building oa-organ 1.0.0-SNAPSHOT [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ oa-organ --- [WARNING] The artifact xml-apis:xml-apis:jar:2.0.2 has been relocated to xml-apis:xml-apis:jar:1.0.b2 [INFO] com.xxxx.oa:oa-organ:jar:1.0.0-SNAPSHOT [INFO] +- org.springframework:spring-core:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-webmvc:jar:3.2.8.RELEASE:compile [INFO] |  +- org.springframework:spring-beans:jar:3.2.8.RELEASE:compile [INFO] |  \- org.springframework:spring-expression:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-context:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-context-support:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-aop:jar:3.2.8.RELEASE:compile [INFO] |  \- aopalliance:aopalliance:jar:1.0:compile [INFO] +- org.springframework:spring-aspects:jar:3.2.8.RELEASE:compile [INFO] |  \- org.aspectj:aspectjweaver:jar:1.7.4:compile [INFO] +- org.springframework:spring-tx:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-jdbc:jar:3.2.8.RELEASE:compile [INFO] +- org.springframework:spring-web:jar:3.2.8.RELEASE:compile [INFO] +- junit:junit:jar:4.13.2:test [INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test [INFO] +- org.springframework:spring-test:jar:3.2.8.RELEASE:test [INFO] +- log4j:log4j:jar:1.2.12:compile [INFO] +- org.slf4j:slf4j-api:jar:1.6.6:compile [INFO] +- org.slf4j:slf4j-log4j12:jar:1.6.6:compile [INFO] +- org.mybatis:mybatis:jar:3.2.1:compile [INFO] +- org.mybatis:mybatis-spring:jar:1.2.0:compile [INFO] \- mysql:mysql-connector-java:jar:5.1.47:compile [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time:  0.938 s [INFO] Finished at: 2021-11-27T23:36:43+08:00 [INFO] ------------------------------------------------------------------------ 与上面对比 [INFO] +- org.springframework:spring-core:jar:3.2.8.RELEASE:compile 下面的这一行 [INFO] |  \- commons-logging:commons-logging:jar:1.1.3:compile 由于刚刚加了exclusions参数设置，导致commons-logging失效 实验成功 ———————————————— 原文链接：https://blog.csdn.net/mxg1120/article/details/121585528 

现在的项目一般是拆分成一个个独立的模块，当在其他项目中想要使用独立出来的这些模块，只需要在其pom.xml使用<dependency>标签来进行jar包的引入即可。 <dependency>其实就是依赖，关于依赖管理里面都涉及哪些内容，我们就一个个来分析下: 依赖传递 可选依赖 排除依赖 我们先来说说什么是依赖: 依赖指当前项目运行所需的jar，一个项目可以设置多个依赖。 格式为:  <!--设置当前项目所依赖的所有jar--> <dependencies>     <!--设置具体的依赖-->     <dependency>         <!--依赖所属群组id-->         <groupId>org.springframework</groupId>         <!--依赖所属项目id-->         <artifactId>spring-webmvc</artifactId>         <!--依赖版本号-->         <version>5.2.10.RELEASE</version>     </dependency> </dependencies> 一、依赖传递与冲突问题 1.1 依赖下钻 比如下面的项目的依赖中 有一个比较大的区别就是有的依赖前面有箭头>,有的依赖前面没有。 那么这个箭头所代表的含义是什么?打开前面的箭头，你会发现这个jar包下面还包含有其他的jar包 1.2 依赖具有传递性 说明:A代表自己的项目；B,C,D,E,F,G代表的是项目所依赖的jar包；D1和D2 E1和E2代表是相同jar包的不同版本 (1) A依赖了B和C,B和C有分别依赖了其他jar包，所以在A项目中就可以使用上面所有jar包，这就是所说的依赖传递 (2) 依赖传递有直接依赖和间接依赖 相对于A来说，A直接依赖B和C,间接依赖了D1,E1,G，F,D2和E2 相对于B来说，B直接依赖了D1和E1,间接依赖了G  直接依赖和间接依赖是一个相对的概念 (3)因为有依赖传递的存在，就会导致jar包在依赖的过程中出现冲突问题，具体什么是冲突?Maven是如何解决冲突的? 这里所说的依赖冲突是指项目依赖的某一个jar包，有多个不同的版本，因而造成类包版本冲突。 情况一: 在pom.xml中添加两个不同版本的Junit依赖:  <dependencies>     <dependency>       <groupId>junit</groupId>       <artifactId>junit</artifactId>       <version>4.12</version>       <scope>test</scope>     </dependency> ​     <dependency>       <groupId>junit</groupId>       <artifactId>junit</artifactId>       <version>4.11</version>       <scope>test</scope>     </dependency> </dependencies> 通过对比，会发现一个结论 特殊优先：当同级配置了相同资源的不同版本，后配置的覆盖先配置的。 情况二: 路径优先：当依赖中出现相同的资源时，层级越深，优先级越低，层级越浅，优先级越高 A通过B间接依赖到E1  A通过C间接依赖到E2 A就会间接依赖到E1和E2,Maven会按照层级来选择，E1是2度，E2是3度，所以最终会选择E1 情况三: 声明优先：当资源在相同层级被依赖时，配置顺序靠前的覆盖配置顺序靠后的 A通过B间接依赖到D1 A通过C间接依赖到D2 D1和D2都是两度，这个时候就不能按照层级来选择，需要按照声明来，谁先声明用谁，也就是说B在C之前声明，这个时候使用的是D1，反之则为D2 但是对应上面这些结果，大家不需要刻意去记它。因为不管Maven怎么选，最终的结果都会在Maven的Dependencies面板中展示出来，展示的是哪个版本，也就是说它选择的就是哪个版本  如果想更全面的查看Maven中各个坐标的依赖关系，可以点击Maven面板中的show Dependencies，例如 在这个视图中就能很明显的展示出jar包之间的相互依赖关系。 二、可选依赖和排除依赖 依赖传递介绍完以后，我们来思考一个问题， maven_02_ssm 依赖了 maven_04_dao maven_04_dao 依赖了 maven_03_pojo 因为现在有依赖传递，所以maven_02_ssm能够使用到maven_03_pojo的内容 如果说现在不想让maven_02_ssm依赖到maven_03_pojo，有哪些解决方案? 说明:在真实使用的过程中，maven_02_ssm中是需要用到maven_03_pojo的，我们这里只是用这个例子描述我们的需求。因为有时候，maven_04_dao出于某些因素的考虑，就是不想让别人使用自己所依赖的maven_03_pojo。  方案一:可选依赖 可选依赖指对外隐藏当前所依赖的资源---指不透明 在maven_04_dao的pom.xml,在引入maven_03_pojo的时候，添加optional  <dependency>     <groupId>com.itheima</groupId>     <artifactId>maven_03_pojo</artifactId>     <version>1.0-SNAPSHOT</version>     <!--可选依赖是隐藏当前工程所依赖的资源，隐藏后对应资源将不具有依赖传递-->     <optional>true</optional> </dependency> 此时就出问题了,说明由于maven_04_dao将maven_03_pojo设置成可选依赖，导致maven_02_ssm无法引用到maven_03_pojo中的内容，导致需要的类找不到。  方案二:排除依赖  排除依赖指主动断开依赖的资源，被排除的资源无需指定版本---指不需要  前面我们已经通过可选依赖实现了阻断maven_03_pojo的依赖传递，对于排除依赖，则指的是已经有依赖的事实，也就是说maven_02_ssm项目中已经通过依赖传递用到了maven_03_pojo，此时我们需要做的是将其进行排除，所以接下来需要修改maven_02_ssm的pom.xml  <dependency>     <groupId>com.itheima</groupId>     <artifactId>maven_04_dao</artifactId>     <version>1.0-SNAPSHOT</version>     <!--排除依赖是隐藏当前资源对应的依赖关系-->     <exclusions>         <exclusion>             <groupId>com.itheima</groupId>             <artifactId>maven_03_pojo</artifactId>         </exclusion>     </exclusions> </dependency> 排除依赖资源仅需指定groupId，artifactId即可，不用指定version，会把不同的版本都排除掉  当然exclusions标签带s说明我们是可以依次排除多个依赖到的jar包，比如maven_04_dao中有依赖junit和mybatis,我们也可以一并将其排除。  <dependency>     <groupId>com.itheima</groupId>     <artifactId>maven_04_dao</artifactId>     <version>1.0-SNAPSHOT</version>     <!--排除依赖是隐藏当前资源对应的依赖关系-->     <exclusions>         <exclusion>             <groupId>com.itheima</groupId>             <artifactId>maven_03_pojo</artifactId>         </exclusion>         <exclusion>             <groupId>log4j</groupId>             <artifactId>log4j</artifactId>         </exclusion>         <exclusion>             <groupId>org.mybatis</groupId>             <artifactId>mybatis</artifactId>         </exclusion>     </exclusions> </dependency>  介绍我这两种方式后，简单来梳理下，就是 A依赖B,B依赖C,C通过依赖传递会被A使用到，现在要想办法让A不去依赖C 可选依赖是在B上设置<optional>,A不知道有C的存在，代表这个依赖是否需要被发现。这种适用于可以修改B的配置文件的情况下 排除依赖是在A上设置<exclusions>,A知道有C的存在，主动将其排除掉。代表这个依赖已经被发现，但自己是否需要引用。这种适用于不能修改B的配置文件的情况下 ———————————————— 原文链接：https://blog.csdn.net/FaithWh/article/details/128211910 

 依赖 依赖关系，可以理解成“USE-A”关系即使用关系。 依赖关系是一种使用关系，如果A类中使用了B类对象，那么就可以说A类依赖B类。  依赖传递 项目A直接依赖项目B，项目B直接依赖项目C，maven会间接地将A依赖C，这就是依赖传递。类/第三方库也是同样的道理。  可选依赖和依赖排除 以上图为例，当需要在项目A中排除对项目C的依赖时，这时又该怎么做呢？Maven 为我们提供了两种解决方案，分别是可选依赖（Optional Dependencies）和依赖排除（Dependency Exclusions）。  什么时候需要排除依赖？ 项目A依赖项目B，但当项目A不是完全依赖项目B的时候，即项目A只用到了项目B的一部分功能，而正巧项目B这部分功能的实现，并不需要依赖于项目C，这个时候，项目A就应该排除对项目C的依赖。  有的人可能有这样的疑问，为什么要排除对项目C的依赖呢？就算包含了对项目C的依赖，也不会出问题啊。事实上，表面上看确实不会出现问题。但是，我们必须记住一点：当我们使用一个工程时，控制实际需要的依赖列表非常重要。而且，排除不必要的依赖还可以帮助我们，节约磁盘、内存等空间，避免许可协议问题以及类路径问题等。我们在享受Maven依赖的自动传递性带给我们的便利的同时，要时刻注意引入冗余、不必要的依赖对我们项目产生的负面影响。  可选依赖（Optional Dependencies） optional英文意思是可选的，可以让子工程自己决定要不要此依赖 默认为false，表示依赖会传递给子工程，子工程没得选，被迫接受该依赖。 如果为true，表示依赖不会传递给子工程。子工程不会有该依赖。当需要时，子工程可以在pom文件中添加该依赖 ———————————————— 原文链接：https://blog.csdn.net/qq_41740883/article/details/106965161 

1、概念介绍 Dependencies：是可选依赖（Optional Dependencies） Exclusions：是依赖排除（Dependency Exclusions） 2、Dependencies （1）当一个项目A依赖另一个项目B时，项目A可能很少一部分功能用到了项目B，此时就可以在A中配置对B的可选依赖。举例来说，一个类似hibernate的项目，它支持对mysql、oracle等各种数据库的支持，但是在引用这个项目时，我们可能只用到其对mysql的支持，此时就可以在这个项目中配置可选依赖。 （2）配置可选依赖的原因： 1）节约磁盘、内存等空间； 2）避免license许可问题； 3）避免类路径问题，等等。 （3）示例：  <project>   ...   <dependencies>     <!-- declare the dependency to be set as optional -->     <dependency>       <groupId>sample.ProjectB</groupId>       <artifactId>Project-B</artifactId>       <version>1.0</version>       <scope>compile</scope>       <optional>true</optional> <!-- value will be true or false only -->     </dependency>   </dependencies> </project>   　　假设以上配置是项目A的配置，即：Project-A –> Project-B。在编译项目A时，是可以正常通过的。如果有一个新的项目X依赖A，即：Project-X -> Project-A。此时项目X就不会依赖项目B了。如果项目X用到了涉及项目B的功能，那么就需要在pom.xml中重新配置对项目B的依赖。假设A->B, B->x（可选）, B->y（可选）。这里由于x，y是可选依赖，依赖不会传递，x，y将不会对a有任何影响  3、Exclusions （1）当一个项目A依赖项目B，而项目B同时依赖项目C，如果项目A中因为各种原因不想引用项目C，在配置项目B的依赖时，可以排除对C的依赖。 （2）示例（假设配置的是A的pom.xml，依赖关系为：A –> B; B –> C）：  <project>   ...   <dependencies>     <dependency>       <groupId>sample.ProjectB</groupId>       <artifactId>Project-B</artifactId>       <version>1.0</version>       <scope>compile</scope>       <exclusions>         <exclusion>  <!-- declare the exclusion here -->           <groupId>sample.ProjectC</groupId>           <artifactId>Project-C</artifactId>         </exclusion>       </exclusions>      </dependency>   </dependencies> </project> 4、maven的依赖调解有两大原则：路径最近者优先；第一声明者优先。 5、maven的归类依赖 <properties> <springframework.version>2.5.6<springframework.version> </properties> ———————————————— 原文链接：https://blog.csdn.net/qq_18671415/article/details/119139686 

IDEA 配置 Git  1、Windows 上 Git 安装完成后就可以在 git 自带的命令行工具中执行 git 命令，IDEA 想要使用 git ，则需要进行简单的配置，类似与 maven 配置一样，指定 git.exe 程序路径即可。 2、配置 git ：File–>Setting–>Version Control–>Git 面板的 Path to Git executable 中选中 git.exe 的位置即完成了 git 的配置。点击右侧的 "Test" 按钮可以检测配置是否成功。 3、所谓的配置：其实就是本机安装完成 git 后，在 IDEA 中检查一下是否连接成功，因为 IDEA 也是通过给本地的 git 客户端发送命令。IDEA 工具在安装的时候就默认安装了 Git 插件。 一、整体合并 团队协作中，开发人员A、B、C分别在dev上进行功能开发，并push代码到远端dev上。当测试人员需要对功能进行测试的时候，我们需要把dev上新增的功能代码合并到test分支上去。 步骤： 1、将dev上的代码push到远端dev上。 2、切换分支到test分支。（就是切换到将要合并的目标分支） 3、拉取代码，确保test分支为远端最新的代码。4、合并分支5、有冲突，先解决冲突后再合并，没有冲突则合并成功。 6、push代码到远端test分支上去。 二、针对某次提交的合并 团队协作中，开发人员较多，采用上面统一合并分支的形式，如果出现冲突，需要询问对应的开发人员进行代码的取舍，有代码丢失和错乱的风险，所以我们在项目开发中会采用遴选合并分支的方式。（自己写的代码，自己合并到对应的目标分支上去） 步骤： 1、在dev分支上，查看提交历史。 2、复制某次提交的版本号。3、切换到test分支（注意：切换成功后，最好pull拉取下代码，再执行下图命令），按下图执行命令。4、大功告成！可以归纳为以下步骤：如把你个人的分支合并到dev分支:     1.切换到dev分支         右下角选择dev分支,checkout即可.需要注意的是:先把你分支提交后再切,不然会有异常     2.右键项目---git---repository---merge changes,选中dev,merge.或者直接点击右下角的dev,在弹出的分支中点击要合并的分支,在弹出的选项中选择merge即可.     3.如果没有冲突,直接提交即可.如果有冲突,则需要解决冲突再提交. ———————————————— 原文链接：https://blog.csdn.net/wucaiyun225/article/details/122844223 

git的smart Checkout跟force checkout的区别在切换分支的时候,常常会遇到下图的问题是因为我在test分支上修改了代码，但是没有commit，切换到其他分支上就弹出了这个窗口我们需要怎么处理呢 可以看到弹框底部有Force Checkout Don`t checkout Smart Checkout,表示什么意思呢 Smart Checkout就会把冲突的这部分内容带到开发分支（如果你没有点进窗口的那些文件处理冲突的话),比如我在test分支修改到代码，要切换到master分支，点击smart checkout后，master分支会有test分支修改到代码，最好是选smart checkout这样会把本地修改的代码先保存到statsh中，再checkout分支。 Force Checkout 就不会把冲突的这部分内容带到开发分支，如果点了force checkout则本地修改都会丢失！！！！！！！！！正确操作是： 切换分支之前，应该先GIT --> Repository --> Stash changes 保存该分支下的改动。 切换回来后，GIT --> Repository --> UnStash changes 恢复之前的改动， Don`t checkout 当然是不切分支,继续留在当前分支了 总结：不要点击force checkout，如果不想当前分支修改到代码出现在要切换到分支中，需要手动Stash changes，如果允许当前分支修改到代码出现在要切换到分支中，可以选择smart checkout 在使用git进行代码版本管理的时候,当我们切换分支的时候,常常会遇到这样的问题:这是因为在develop分支修改了代码,但是没有commit,所以在切换到其他分支的时候回弹出这个窗口.那么我们改怎么做呢? smart checkout就会把冲突的这部分内容带到目的分支（如果你没有点进窗口的那些文件处理冲突的话） force checkout就不会把冲突的这部分内容带到目的分支,但是你在当前分支修改的所有内容就会被删除,就算你再切回来也找不到了,所以需要慎重哦 don`t checkout 当然是不切分支,继续留在当前分支了 。在当前分支修改了代码，但是没有commit,所以在切换到其他分支的时候会弹出这个窗口，提示你选force checkout或者smart checkout。那该怎样处理呢？don`t checkout 是不切分支,继续留在当前分支；smart checkout会把冲突的这部分内容带到目的分支（如果你没有点进窗口的那些文件处理冲突的话）；force checkout就不会把冲突的这部分内容带到目的分支,但是你在当前分支修改的所有内容都会丢失,就算你再切回来会找不到,需要慎重操作。———————————————— 原文链接：https://blog.csdn.net/Andrew_Chenwq/article/details/129717762 

1、概念介绍 Maven项目对象模型(POM)，可以通过一小段描述信息来管理项目的构建，报告和文档的项目管理工具软件。 Maven 除了以程序构建能力为特色之外，还提供高级项目管理工具。由于 Maven 的缺省构建规则有较高的可重用性，所以常常用两三行 Maven 构建脚本就可以构建简单的项目。由于 Maven 的面向项目的方法，许多 Apache Jakarta 项目发文时使用 Maven，而且公司项目采用 Maven 的比例在持续增长。 Maven这个单词来自于意第绪语（犹太语），意为知识的积累，最初在Jakata Turbine项目中用来简化构建过程。当时有一些项目（有各自Ant build文件），仅有细微的差别，而JAR文件都由CVS来维护。于是希望有一种标准化的方式构建项目，一个清晰的方式定义项目的组成，一个容易的方式发布项目的信息，以及一种简单的方式在多个项目共享JARs。Dependencies：是可选依赖（Optional Dependencies） Exclusions：是依赖排除（Dependency Exclusions） 2、Dependencies （1）当一个项目A依赖另一个项目B时，项目A可能很少一部分功能用到了项目B，此时就可以在A中配置对B的可选依赖。举例来说，一个类似hibernate的项目，它支持对mysql、oracle等各种数据库的支持，但是在引用这个项目时，我们可能只用到其对mysql的支持，此时就可以在这个项目中配置可选依赖。 （2）配置可选依赖的原因： 1）节约磁盘、内存等空间； 2）避免license许可问题； 3）避免类路径问题，等等。 （3）示例： <project>   ...   <dependencies>     <!-- declare the dependency to be set as optional -->     <dependency>       <groupId>sample.ProjectB</groupId>       <artifactId>Project-B</artifactId>       <version>1.0</version>       <scope>compile</scope>       <optional>true</optional> <!-- value will be true or false only -->     </dependency>   </dependencies> </project> 　　假设以上配置是项目A的配置，即：Project-A –> Project-B。在编译项目A时，是可以正常通过的。如果有一个新的项目X依赖A，即：Project-X -> Project-A。此时项目X就不会依赖项目B了。如果项目X用到了涉及项目B的功能，那么就需要在pom.xml中重新配置对项目B的依赖。假设A->B, B->x（可选）, B->y（可选）。这里由于x，y是可选依赖，依赖不会传递，x，y将不会对a有任何影响 3、Exclusions （1）当一个项目A依赖项目B，而项目B同时依赖项目C，如果项目A中因为各种原因不想引用项目C，在配置项目B的依赖时，可以排除对C的依赖。 （2）示例（假设配置的是A的pom.xml，依赖关系为：A –> B; B –> C）：  <project>   ...   <dependencies>     <dependency>       <groupId>sample.ProjectB</groupId>       <artifactId>Project-B</artifactId>       <version>1.0</version>       <scope>compile</scope>       <exclusions>         <exclusion>  <!-- declare the exclusion here -->           <groupId>sample.ProjectC</groupId>           <artifactId>Project-C</artifactId>         </exclusion>       </exclusions>      </dependency>   </dependencies> </project>   4、maven的依赖调解有两大原则：路径最近者优先；第一声明者优先。 5、maven的归类依赖  <properties> <springframework.version>2.5.6<springframework.version> </properties> ———————————————— 原文链接：https://blog.csdn.net/qq_18671415/article/details/119139686 

这篇文章主要介绍了使用idea解决maven依赖冲突,本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下前言：Maven项目对象模型(POM)，可以通过一小段描述信息来管理项目的构建，报告和文档的项目管理工具软件。 Maven 除了以程序构建能力为特色之外，还提供高级项目管理工具。由于 Maven 的缺省构建规则有较高的可重用性，所以常常用两三行 Maven 构建脚本就可以构建简单的项目。由于 Maven 的面向项目的方法，许多 Apache Jakarta 项目发文时使用 Maven，而且公司项目采用 Maven 的比例在持续增长。 Maven这个单词来自于意第绪语（犹太语），意为知识的积累，最初在Jakata Turbine项目中用来简化构建过程。当时有一些项目（有各自Ant build文件），仅有细微的差别，而JAR文件都由CVS来维护。于是希望有一种标准化的方式构建项目，一个清晰的方式定义项目的组成，一个容易的方式发布项目的信息，以及一种简单的方式在多个项目中享JARs。我们进行用maven 开发组件的时候，经常会遇到一种情况，我们添加一些maven依赖后，经常会出现本地原本正常的代码编译不过去下面我们就将这种问题的解决思路和解决方案逐步讲解记录报错的那几个类将刚才添加的maven依赖都还原找到刚才报错的类的jar包的版本号 例如我们的文件fastjson-1.2.58还原刚才加入的maven依赖在刚才编译报错的maven 模块上构建maven依赖体系结果如下图所示6.在构建结果中按ctrl+F7.输入报错的jar包的名字8.选中一个点进去这个时候就可以看到有jar包冲突了我们可以看一下是哪些依赖中有冲突了这样就可以清晰的看清楚maven的依赖关系9.选中一个jar点进就可以看到这个jar的引入的详细信息这样我们就能确定是哪个依赖引入了错误的依赖了。10.在对应不需要的依赖剔除依赖了刷新依赖关系就可以解决依赖混乱的问题123456789101112<dependency>      <groupId>xxx.xxx.xx</groupId>      <artifactId>xxx.xxx.xx</artifactId>      <version>${xx}</version>      <exclusions>        <exclusion>          <groupId>com.alibaba</groupId>          <artifactId>fastjson</artifactId>        </exclusion>      </exclusions>    </dependency>刷新maven依赖关系就可以正常编译成功了到此这篇关于使用idea解决maven依赖冲突的文章就介绍到这了,更多相关idea解决maven依赖冲突内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！原文链接：https://www.jb51.net/article/202539.htm

 问题出现 SpringBoot工程启动不起来，报错Unable to start ServletWebServerApplicationContext due to missing ServletWebServerFactory bean.什么都没有动项目就没起来，网上搜了一些答案说什么是注解没添加到位，或者没有配置内置tomcat的原因。  但是返回到工程里面去看，发现完全不是这么回事，首先注解是没问题的，我没有添加自己的tomcat，内置的tomcat在POM文件里是配置好的，关键是这个项目在服务器上各个环境都是正常的。  问题在哪，我最后找了一圈发现由于pom文件对应的pom文件内置tomcat的写法上  问题出现前是这样的  <dependency>             <groupId>org.springframework.boot</groupId>             <artifactId>spring-boot-starter-tomcat</artifactId>             <scope>provided</scope>         </dependency>  <dependency>  compile （编译范围）  compile是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范围。编译范围依赖在所有的classpath 中可用，同时它们也会被打包。  provided （已提供范围）  provided 依赖只有在当JDK 或者一个容器已提供该依赖之后才使用。例如， 如果你开发了一个web 应用，你可能在编译 classpath 中需要可用的Servlet API 来编译一个servlet，但是你不会想要在打包好的WAR 中包含这个Servlet API；这个Servlet API JAR 由你的应用服务器或者servlet 容器提供。已提供范围的依赖在编译classpath （不是运行时）可用。它们不是传递性的，也不会被打包。  runtime （运行时范围）  runtime 依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，你可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC 驱动实现。  test （测试范围）  test范围依赖 在一般的编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。  system （系统范围）  system范围依赖与provided 类似，但是你必须显式的提供一个对于本地系统中JAR 文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库的一部分。这样的构件应该是一直可用的，Maven 也不会在仓库中去寻找它。如果你将一个依赖范围设置成系统范围，你必须同时提供一个 systemPath 元素。注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的 Maven 仓库中引用依赖）。 

Non-resolvable parent POM: Could not find artifact com.ecp:ecp-main:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 8, column 10 -> [Help 2] 原因：多模块项目构建时，先将parent项目要先install一回，之后子项目才可以运行mvn compile命令,否则就会报如上异常解决办法：首先双击父工程install然后双击子模块的install