部署行家文物改变只

比方说，我有一个POM结构是这样的（具有相应版本）

parentproj, v1.0.1 
- childproj1, v1.0.2 
- childproj2, v1.0.7

childproj1和childproj2代表不同部分应用程序（例如gui和后端），我希望能够将它们的版本分开，以便我可以发布新版本的后端，而无需发布新版本的gui。

现在，部署此结构关系，因此很方便去parentproj说

MVN部署-DperformRelease =真

这将部署的所有文物，Nexus的realease库。这工作得很好，我第一次部署它，但我第二次碰到的问题：让我们说，我做了一个更新childproj1使我们现在有以下版本：

parentproj, v1.0.1 
- childproj1, v1.0.3 
- childproj2, v1.0.7

在这种情况下的Nexus不会让我从parentproj进行mvn部署，因为它已经在1.0.7版本中有了一个childproj2的副本。 Nexus会说“资源，非法请求：ID ='发行版'的版本库不允许更新工件。”这很好，我不想错误地更新现有版本。

但我想我想要做的是能够告诉maven类似于“仅部署那些版本尚未存在于发布存储库中的工件”。

有没有办法做到这一点，还是我必须自己部署每个项目？

来源

2009-12-07 David

根据我的经验，部署一切都变得更加容易，并且通常对所有组件使用相同的版本号。例如，如果我的团队正在使用版本1.0.7，则所有子模块的版本号为1.0.7-SNAPSHOT，直到我们发布，即使某些模块中没有代码发生更改。然后，当我们部署时，我们将部署整个应用程序。我认为它比零碎的部署有几个优点。首先，如果你必须回滚到最后一个稳定版本，你只需要回滚到1.0.6所有模块 - 你不必记住后端是1.0.3而GUI是1.0.6。其次，它确保所有组件都相互正确编译，并作为逻辑组进行测试。

对不起，我知道这是不是一个具体的回答你的问题，但是，至少在我的球队的情况下，有人认为略有不同有用

来源

2009-12-07 14:41:05

谢谢你的回答约翰，我们也在调查这种方法，它很可能是最后采取的方法。我同意版本一致性带来很多价值，但是我也担心，如果您需要升级整个平台以进行任何更改，那么对于大型项目来说，构建过程可能会太臃肿和耗时。 – David 2009-12-07 14:54:28

+1，用于暗示版本上的SNAPSHOT限定符（正确且正确）的用法以解决此问题。 – whaley 2011-07-21 14:55:45

我不同意关于被一起编译和一起测试的最后声明。如果你在JAR上有固定的版本依赖关系，Maven将使用这些JAR编译你的项目，这样你仍然可以用SNAPSHOT或固定的版本依赖关系来编译所有的东西。至于测试，通过真正的单元测试，我认为应该嘲笑类依赖，特别是JAR边界。这意味着你的代码不会一起测试，除非你有针对部署的应用程序运行某种功能/集成测试，那么SNAPSHOT或固定版本不会再出现问题。 – 2011-07-22 06:43:30

我建议，如果你计划维护，建设并独立部署模块，则应考虑为每个模块设置单独的CI和mvn deploy作业。拥有独立的mvn deploy职位将为您提供您正在寻找的开箱即用行为。这意味着不使用aggregator pom（parentprj）来尝试构建和部署这些模块。

如果你想做一切从聚合pom，如建立和部署，那么我会建议按照约翰的答案，并保持所有版本号同步。

这只取决于你的团队如何看待代码库。如果你想以真正的模块化方式来保存东西，你应该使用像构建块这样的Maven模块，对它们进行不同的处理，直到你准备将整个应用程序放在一起。如果你的应用在性质上更加单一，那么把它看作是一样的，并保持同步。这并不意味着你仍然不能分开用于维护代码库模块性的单独的Maven模块，只是认识到它们没有任何超出大型应用程序环境的价值。

做出这个决定是问自己的一个好办法“将任何其它项目/应用程序需要引用这个模块作为一个依赖？”。如果是这样，最好的做法是独立构建，版本和部署。如果没有，我没有看到使版本匹配的任何缺陷。

来源

2011-07-15 19:24:56

首先，我认为你应该区分父项目和聚合项目。父项目应该用于几个项目通用的设置，例如依赖关系的版本;应该使用聚合项目来同时构建一组项目，例如，一组瓶子和包含它们的战争。

这两种项目最好保持分开。父项目通常不会经常更改，并且通常最好是发布所有依赖项目的新版本;聚合项目的唯一目的是推动一堆项目的构建，所以只要其包含的项目中的一个项目需要发布，它的发布号码就可能会发生变化。

将父母与聚合器分离后，您可以更好地选择是否遵循John Paulett的建议并将所有内容保留在相同的版本号上，或仅在实际需要时尝试更改每个项目的版本号释放它。第一个选项更简单，不易出错，但会导致您发布未更改的新版本库。例如，如果您需要发布补丁而不是完整版本，这可能是不可接受的。第二种选择更复杂且容易出错，但会导致您的版本号与您的软件的发展相匹配。 Maven发布插件和Jenkins持续集成工具可能对此有所帮助，我想你应该检查一下。此外，请查看您是否可以将Maven升级至2.2.1版和Nexus版以更新版本。

来源

2011-07-21 21:12:08

+1用于区分母公司与集合商POM。有关差异的更多详细信息，请阅读有关POM继承和聚合的内容：http://maven.apache.org/guides/introduction/introduction-to-the-pom.html – 2011-07-22 06:50:12

很显然，这个需求并非由Nexus或archiva的maven解决。现在只能通过构建管理器设置的其他技巧解决，比如之前发布的建议。

在一个理想的世界

聚甲醛将包括
。发布版本和快照版本的模块
。文件的定义，如果更改，则证明使用快照版本
。被释放模块的源代码控制管理系统参考
相关模块劲歌将在适当的依赖部分的发行版本信息，因此如果目前它链接到快照库回购旁边添加快照版本信息和释放库，否则
行家反应器将有一个选项，阅读都依赖层次结构和文件更改信息（SCM DIFF）知道一个给定的模块是否在其发布或快照版本中使用。
发布插件默认情况下会根据文件更改和依赖性信息跳过仍然可以与其发布版本一起使用的模块的发布。

来源

2015-03-04 10:24:15 eygm

部署行家文物改变只

回答

相关问题