我们有一个依赖于资源的Web应用程序(Java Tomcat Spring Maven).因此app-1.0.1.war取决于resources-1.0.3.jar.当我们需要修复资源中的错误时,我们需要
>发布一个新的资源罐=> 1.0.4
>更新Web应用程序的Maven Pom中的依赖关系
>发动新战争=> 1.0.2
>部署网络应用
在我们团队中,有人认为这不是一种有效的方法.他们宁愿
>释放一个新罐子
>在服务器上上传jar
因此,基本上没有重新部署该应用程序.似乎更容易,但是我可以看到这种方法的几个问题：
>您需要对包含资源的jar的名称进行硬编码.
>您不知道该应用程序正在使用的资源的版本.
更新Web应用程序静态资源的常用做法是什么？
>发布一个新的资源罐=> 1.0.4
>更新Web应用程序的Maven Pom中的依赖关系
>发动新战争=> 1.0.2
>部署网络应用
这样做有很多原因,其中一些是对我很重要的原因：
>我们的内部jar文件(模块)可在许多项目中重复使用.较旧的项目可能会随着新版本的发布而中断.
>虽然为单个应用程序编写的点版本可能不会造成任何麻烦,但是大量发行会破坏整个应用程序.在进行此类发布之前,将需要进行认真的集成测试.
>如果您具有相互依赖性,例如主应用程序需要版本1.0.4,而另一个模块需要1.0.1,则主应用程序将始终赢得决胜局.如果版本1.0.4破坏了上述模块,则必须对其进行修复,然后才能部署您的项目.
如果这些都不适合您,请考虑阅读Maven文档中的Dependency Version Ranges.这样的事情应该可以完成您想要做的事情：
<version>LATEST</version>
编辑：
So basically no redeployment of the app
这是不正确的,资源只会在每次运行mvn安装时(每次构建战争时)才更新.
因此,是的,在开发过程中,您将始终拥有最新的jar,但较旧的战争不会突然与新发布的jar捆绑在一起.相信我,您绝对不想要那样.
您只需要减少一个步骤：
>更新Web应用程序的Maven Pom中的依赖关系
