Maven依赖的是本地工程还是仓库jar包
3个回答
展开全部
相信大家都碰见过 maven 配置的依赖或者是 jar 包或者是工程,在开发的过程当中,我们当然需要引入的是工程,这样查看 maven 依赖的文件的时候,就能直接查看到源码。
一、本地工程依赖
举个例子,其架构如下所示(以下均使用eclipse中m2eclipse插件进行演示)——
此时,这里依赖的“dependency-to-hello”指代的是eclipse工作空间中的工程,这样,我们直接源码依赖的便是工作空间里的源码,这样很方便,也是我们需要的。会注意到,所依赖的“dependency-to-hello”工程,并没有显示其路径,也就是默认的工作空间的地址。
那么,什么时候maven依赖的是仓库(本地仓库或远程仓库)中的jar包呢?
二、(本地/远程)仓库jar包依赖
很简单的方法之一,直接把“dependency-to-hello”工程关闭掉(close project),这样,就得到这样一个视图——
会看到,此时maven依赖的正是对应“dependency-to-hello”工程的jar文件,并且,后面的路径显示是从maven仓库里面取的。
三、工程依赖及仓库依赖的转换
OK,我们现在还原之,我们将工程“dependency-to-hello”打开,会看到对应的maven依赖又变回原来的工程依赖了。
需要说的是,当重新打开工程“dependency-to-hello”的时候,hello工程并没有出现红色感叹号,也就是无须做“update dependencies”等的更新maven依赖等操作。
从这里,我们就能够看出来——m2eclipse首先查看是否能够从本地工程库中得到对应的maven依赖,如何存在,则将本地工程依赖进来;如何不存在,则从本地仓库/远程仓库中加载解析对应的jar包依赖。
一、本地工程依赖
举个例子,其架构如下所示(以下均使用eclipse中m2eclipse插件进行演示)——
此时,这里依赖的“dependency-to-hello”指代的是eclipse工作空间中的工程,这样,我们直接源码依赖的便是工作空间里的源码,这样很方便,也是我们需要的。会注意到,所依赖的“dependency-to-hello”工程,并没有显示其路径,也就是默认的工作空间的地址。
那么,什么时候maven依赖的是仓库(本地仓库或远程仓库)中的jar包呢?
二、(本地/远程)仓库jar包依赖
很简单的方法之一,直接把“dependency-to-hello”工程关闭掉(close project),这样,就得到这样一个视图——
会看到,此时maven依赖的正是对应“dependency-to-hello”工程的jar文件,并且,后面的路径显示是从maven仓库里面取的。
三、工程依赖及仓库依赖的转换
OK,我们现在还原之,我们将工程“dependency-to-hello”打开,会看到对应的maven依赖又变回原来的工程依赖了。
需要说的是,当重新打开工程“dependency-to-hello”的时候,hello工程并没有出现红色感叹号,也就是无须做“update dependencies”等的更新maven依赖等操作。
从这里,我们就能够看出来——m2eclipse首先查看是否能够从本地工程库中得到对应的maven依赖,如何存在,则将本地工程依赖进来;如何不存在,则从本地仓库/远程仓库中加载解析对应的jar包依赖。
展开全部
相信大家都碰见过maven配置的依赖或者是jar包或者是工程,在开发的过程当中,我们当然需要引入的是工程,这样查看maven依赖的文件的时候,就能直接查看到源码。
一、本地工程依赖
举个例子,其架构如下所示(以下均使用eclipse中m2eclipse插件进行演示)——
此时,这里依赖的“dependency-to-hello”指代的是eclipse工作空间中的工程,这样,我们直接源码依赖的便是工作空间里的源码,这样很方便,也是我们需要的。会注意到,所依赖的“dependency-to-hello”工程,并没有显示其路径,也就是默认的工作空间的地址。
那么,什么时候maven依赖的是仓库(本地仓库或远程仓库)中的jar包呢?
二、(本地/远程)仓库jar包依赖
很简单的方法之一,直接把“dependency-to-hello”工程关闭掉(close project),这样,就得到这样一个视图——
会看到,此时maven依赖的正是对应“dependency-to-hello”工程的jar文件,并且,后面的路径显示是从maven仓库里面取的。
三、工程依赖及仓库依赖的转换
OK,我们现在还原之,我们将工程“dependency-to-hello”打开,会看到对应的maven依赖又变回原来的工程依赖了。
需要说的是,当重新打开工程“dependency-to-hello”的时候,hello工程并没有出现红色感叹号,也就是无须做“update dependencies”等的更新maven依赖等操作。
从这里,我们就能够看出来——m2eclipse首先查看是否能够从本地工程库中得到对应的maven依赖,如何存在,则将本地工程依赖进来;如何不存在,则从本地仓库/远程仓库中加载解析对应的jar包依赖。
四、版本号变更
在这儿,我假装模拟一下版本号变更,来看一下,会发生什么情况?
现在“dependency-to-hello”工程是“快照”版本,当我们将之换为正式版本的时候,发现“hello”工程的maven依赖重新变回了jar依赖,如下——
“dependency-to-hello”工程的maven坐标配置——
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>dependency-to-hello</artifactId>
<version>0.0.1</version>
<packaging>jar</packaging>
“hello”工程的依赖配置——
<dependency>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>dependency-to-hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
其文件架构会显示如下——
会发现其依赖是原有的仓库中的“快照”版本的“dependency-to-hello”的jar包。我们将仓库中的“快照”版本删除掉。刷新工程,发现hello工程上显示红色感叹号。如下——
也就是说,其依赖是空依赖,本地及仓库中均不存在。
当然这个“陷阱”是我自己加的,重新更改其版本号正确对应即可,就可以重新得到maven本地工程依赖了。
五、总结
在日常多人协作开发过程中,我们常常会遇到maven依赖版本变更带来的问题。当我们的工作空间也存在对应的依赖工程(对应上述例子中的“dependency-to-hello”工程)的时候,我们可以通过判断依赖的是本地工程还是仓库jar包的方式来判断是否出现了版本不一致的问题。从而,就能够解决maven依赖版本变更带来的问题。
一、本地工程依赖
举个例子,其架构如下所示(以下均使用eclipse中m2eclipse插件进行演示)——
此时,这里依赖的“dependency-to-hello”指代的是eclipse工作空间中的工程,这样,我们直接源码依赖的便是工作空间里的源码,这样很方便,也是我们需要的。会注意到,所依赖的“dependency-to-hello”工程,并没有显示其路径,也就是默认的工作空间的地址。
那么,什么时候maven依赖的是仓库(本地仓库或远程仓库)中的jar包呢?
二、(本地/远程)仓库jar包依赖
很简单的方法之一,直接把“dependency-to-hello”工程关闭掉(close project),这样,就得到这样一个视图——
会看到,此时maven依赖的正是对应“dependency-to-hello”工程的jar文件,并且,后面的路径显示是从maven仓库里面取的。
三、工程依赖及仓库依赖的转换
OK,我们现在还原之,我们将工程“dependency-to-hello”打开,会看到对应的maven依赖又变回原来的工程依赖了。
需要说的是,当重新打开工程“dependency-to-hello”的时候,hello工程并没有出现红色感叹号,也就是无须做“update dependencies”等的更新maven依赖等操作。
从这里,我们就能够看出来——m2eclipse首先查看是否能够从本地工程库中得到对应的maven依赖,如何存在,则将本地工程依赖进来;如何不存在,则从本地仓库/远程仓库中加载解析对应的jar包依赖。
四、版本号变更
在这儿,我假装模拟一下版本号变更,来看一下,会发生什么情况?
现在“dependency-to-hello”工程是“快照”版本,当我们将之换为正式版本的时候,发现“hello”工程的maven依赖重新变回了jar依赖,如下——
“dependency-to-hello”工程的maven坐标配置——
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>dependency-to-hello</artifactId>
<version>0.0.1</version>
<packaging>jar</packaging>
“hello”工程的依赖配置——
<dependency>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>dependency-to-hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
其文件架构会显示如下——
会发现其依赖是原有的仓库中的“快照”版本的“dependency-to-hello”的jar包。我们将仓库中的“快照”版本删除掉。刷新工程,发现hello工程上显示红色感叹号。如下——
也就是说,其依赖是空依赖,本地及仓库中均不存在。
当然这个“陷阱”是我自己加的,重新更改其版本号正确对应即可,就可以重新得到maven本地工程依赖了。
五、总结
在日常多人协作开发过程中,我们常常会遇到maven依赖版本变更带来的问题。当我们的工作空间也存在对应的依赖工程(对应上述例子中的“dependency-to-hello”工程)的时候,我们可以通过判断依赖的是本地工程还是仓库jar包的方式来判断是否出现了版本不一致的问题。从而,就能够解决maven依赖版本变更带来的问题。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
2018-07-27 · 【免费测试,验证码5秒必达】
北京巴卜技术有限公司
北京巴卜技术有限公司(以下简称巴卜)是具备国际水准的移动商务平台技术和应用方案提供商。自成立以来,巴卜始终 致力于为国内外企业提供具备国际技术水准的移动商务平台及运营服务。
向TA提问
关注
展开全部
我也遇到了两次这样的问题,但解决方法不一样。网上Maven的教程很多,但真正解决日常使用问题的,太少;1、解决法就是:右键项目,【Maven】--》【UpdateProjectConfiguration】Tips:根据Maven插件版本的问题,【UpdateProjectConfiguration】这个东西有的时候是打勾的,有的时候就是个JMenuItem2、我想第一种就可以了,第二种就给你地址吧
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询