根据《Maven实战》介绍,通过maven构建的服务寻找jar包的定位就是通过坐标,也就(groupid,atficatid,version) 去仓库里面找,同样的坐标的jar在本地仓库存在的话,就不会找远程仓库,远程仓库即使又更新,本地的仓库也不会再更新 。因此会造成一个问题,我们如果改了程序,必须要不断的升级版本,这无疑给被引用方带来开发的繁琐,特别时开发期间,可能需要频繁的改动,引用的又多的话,简直就是灾难。
因此Maven设计出snapshot这种版本就是为了解决这个问题。
它的原理其实也就是发布方在deploy到远程仓库的时候加上时间戳,然后被引用的地方,发现时snapshot版本,会比对远程仓库和本地仓库的该版本的时间戳,如果远程又该版本又更新了,则下载到本地仓库,并工程引用。
但是什么时候会去检查呢,这其实时依赖还一个检查配置,就是snapshot版本的更新策略,我们可以配置的pom文件中,或者settings.xml中,分别是
always(一直),daily(默认,每日),interval:X(这里X是以分钟为单位的时间间隔),或者never(从不)
<repository> <id>1111</id> <name>ssss</name> <url>http://localhost:8081/nexus/content/groups/public/</url> <snapshots> <enabled>true</enabled> <updatePolicy>always</updatePolicy> </snapshots> </repository>
一般情况下,我们声明snapshot版本的更新策略肯定都是always,期望拿到该版本最新的jar。
基于以上配置,根据《maven实战》的说法 一开始我的理解只要这样配置好后,maven会开启内部线程不断的对比本地和远程仓库的版本差异,被引用的时候,总能下载好,然后又引用的地方直接指向它。
结果错了,工程里面,引用的还是老的jar,即使我普通的maven updated更新操作,都不顶用,
怀疑配置的always是否真的生效了
后面反复的实验,注意到其中有段话,引用的地方在构建的时候能拿到最新的内容,文中提到【构建】时总
于是我尝试使用maven相关的命令,如 bulid,test等 等一系列的发现此时才去下载,普通的run application
其实没有触发maven的检查机制。
[INFO] Downloading from repo: http://localhost:8081/nexus/content/groups/public/org/example/aa/1.0-SNAPSHOT/maven-metadata.xml [INFO] Downloaded from repo: http://localhost:8081/nexus/content/groups/public/org/example/aa/1.0-SNAPSHOT/maven-metadata.xml (757 B at 3.1 kB/s) [INFO] Downloading from repo: http://localhost:8081/nexus/content/groups/public/org/example/aa/1.0-SNAPSHOT/aa-1.0-20200926.152119-8.pom [INFO] Downloaded from repo: http://localhost:8081/nexus/content/groups/public/org/example/aa/1.0-SNAPSHOT/aa-1.0-20200926.152119-8.pom (855 B at 22 kB/s) [INFO] Downloading from repo: http://localhost:8081/nexus/content/groups/public/org/example/aa/1.0-SNAPSHOT/aa-1.0-20200926.152119-8.jar [INFO] Downloaded from repo: http://localhost:8081/nexus/content/groups/public/org/example/aa/1.0-SNAPSHOT/aa-1.0-20200926.152119-8.jar (2.3 kB at 83 kB/s) [INFO]
顿时发现,有些东西不试真的不知道有坑,想当然的以为只是你以为。
其他:
如果时非snapshot版本,本地install可以覆盖,但是想deploy时不行的,
Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7: deploy (default-deploy) on project aa: Failed to deploy artifacts: Could not transfer artifact org.example:aa:jar:1.3 from/to local-releases (http://localhost:8081/nexus/content/repositories/releases/): Transfer failed for http://localhost:8081/nexus/content/repositories/releases/org/example/aa/1.3/aa-1.3.jar 400 Bad Request
原来是 nexus 中仓库指定的Deployment Policy 版本默认是Disable Redeploy
我猜想这个就是这样子了,远程仓库大家公用的禁止覆盖的,这也有道理,你玩可以。
即使改成可以Redeploy enable ,可以部署成功,但是本地仓库也不会更新,即使配置更新策略为always。
相关推荐
- `updatePolicy`:设定Maven检查远程仓库更新的频率。默认值为`daily`,意味着每天检查一次。其他可选值包括`never`(从不检查)、`always`(每次构建都检查)以及`interval:X`(每隔X分钟检查一次)。 - `...
7. **更新检查频率(Update Policies)**:通过 `<updatePolicy>`,你可以设置Maven检查远程仓库中更新的频率,例如每天、每周或从不检查。 8. **验证设置(Checksum Policies)**:Maven可以验证从远程仓库下载的...
- **`updatePolicy`**:设置仓库更新策略,如 `always`、`daily` 或 `never`。 ### 私有仓库配置 在提供的文件列表中,我们看到了 `settings - 私有仓库配置方式.xml`,这可能是一个示例或模板,用于演示如何在 `...
- **updatePolicy**: 配置Maven检查更新的频率。 - `never`: 从不检查更新。 - `always`: 每次构建时都检查更新。 - `interval:X`: 每隔X分钟检查一次更新。 - **checksumPolicy**: 配置Maven如何处理校验和文件...
<updatePolicy>always</updatePolicy> <enabled>true <updatePolicy>always</updatePolicy> <id>pentaho-public <name>PentahoPublic <url>http://nexus.pentaho.org/content/groups/omni</url>...
<updatePolicy>never</updatePolicy> <enabled>false <id>opendaylight-mirror <name>opendaylight-mirror <url>http://nexus.opendaylight.org/content/repositories/public/</url> ...
│ 第124节:监控状态和身份验证.avi │ 第125节:备份和恢复.avi │ 第126节:Java操作MongoDB.avi │ 第127节:MongoDB和Spring.avi │ 第128节:应用建议及最佳实践.avi │ 第129节:MongoDB结合应用开发一.avi ...