使用git存储库和jenkins执行子项目的maven发布 安装程序

我有一个带有子项目的项目，想做一个maven版本的子项目（项目B）：

Project-A的文件夹同时是我的git存储库，我从我们的中央git服务器克隆了它

对于我们的版本，我们使用jenkins as构建服务器和jenkins Maven发布插件来启动发布构建

因此，在jenkins作业（称为JobB）启动后，它会将Project-A文件夹签出到以下位置：

/Users/titan/.jenkins/jobs/JobB/workspace

由于git的工作方式，我只能克隆结构的顶层。因此，这意味着我需要将我要在jenkins中构建的pom设置为Project-B/pom.xml，然后它将更改maven用于执行其工作的工作目录

当maven发布插件试图提交到错误的目录时（它假设Project-a/Project-B/是有效的git存储库），这就给git带来了很多问题。我可以解决所有这些问题（通过在发布时停用对远程回购的推送，并在发布时指定正确的scm url）

这是jenkins JobB配置中发布目标和选项字段的值：

-X -DpreparationGoals="clean install" 
-DpushChanges=false 
-DconnectionUrl=scm:git:file:///Users/titan/.jenkins/jobs/JobB/workspace 
release:prepare release:perform

需要connectionUrl的文件url，因为我不会将更改推送到git远程服务器，并且在maven:perform开始时完成的克隆将找不到需要签出的标记

问题 毕竟这是我无法解决的问题：

maven:prepare步骤贯穿整个过程并完成所有工作（在pom中更改版本号，创建发布标签）。 然后启动

maven:perform

步骤，从git存储库克隆内容，将签出标记签入目标文件夹，然后调用deploy命令

但问题是调用的deploy命令是在顶层调用的，因此它部署的是Project-A而不是Project-B。作业本身运行时没有任何错误，只是构建和部署了错误的东西

以下是maven生成的用于执行部署的命令：

[INFO] Executing goals 'deploy'...
[DEBUG] Using ${maven.home} of: '/usr/share/java/maven-3.0.3'.
[DEBUG] Executing: /bin/sh -c cd /Users/titan/.jenkins/jobs/jobB/workspace/Project-B/target/checkout && /usr/share/java/maven-3.0.3/bin/mvn -B -X -D maven.repo.local=/Users/titan/.m2/repository -s /Users/titan/.m2/settings.xml -D performRelease=true deploy

因此，它调用了checkout目录中的pom文件，而不是checkout/Project-B中的pom文件。有趣的是，maven:prepare步骤确实在正确的pom上执行

到目前为止我试过什么

• 不使用jenkins，直接从shell调用mvm命令。这给了我同样的结果。所以我认为詹金斯不是问题所在

• 使用

  -Darguments=“-f swarm packaging wbf/pom.xml”

  和

  -Darguments=“-DpomFileName=swarm packaging wbf/pom.xml”

  这两种方法都不会改变结果。查看输出，我发现在生成的命令中，

  -f

  被忽略，其中，

  -DpomFileName

  可见，但不会改变结果中的任何内容

---

所以这意味着你的组织完全错了。将您的父母放入一个单独的maven模块（也可以是单独的git repos）并释放它。在您的子模块中，只需使用父模块，将您的子模块与maven模块以及git repos分开，然后分别发布它们。就这样。否则，您将与Maven展开战斗，您将失去战斗。
听起来您对项目的起源是错误的，因为如果您试图发布子模块，它应该是一个单独的项目。如果你的项目-A没有真正的意义，或者正如你写的那样，你没有发布它，那么在你的项目-A中有一个父pom是有意义的。我不明白为什么你不喜欢发布你的项目-A而不是项目BI。我认为我的名字错了，在这种情况下，我不应该谈论子模块。因为Projekt-B实际上只是project-a的一个子项目。project-a只是一个pom，其中包含了project-a所需的一些插件设置（我不仅有project-B，还有project-C和D，project-a只包含了构建的通用规则）。这正是我所认为的。您的子模块中是否有父标记？如果是，您有一个多模块构建。在这种情况下，您必须释放父模块（这意味着也将释放子模块），而不仅仅是子模块。此外，如果一个多模块构建的所有child和父项都已发布，则如果需要，每个child都可以单独用作依赖项。是的，我的child中有一个parent标记。但是我在父级中没有模块标记。因此，父项目的构建不会构建任何子项目。对我来说，将模块标签放入父模块也没有任何意义，因为子模块在不同的时间构建，并且不共享相同的版本。因此，这意味着您的组织完全错了。将您的父母放入一个单独的maven模块（也可以是单独的git repos）并释放它。在您的子模块中，只需使用父模块，将您的子模块与maven模块以及git repos分开，然后分别发布它们。就这样。否则，你开始与Maven战斗，你将失去战斗。这个答案对我来说是完整的：当使用Maven发布插件的2.2.2版本时，当从顶级文件夹（使用-f参数）开始发布时，该版本就可以工作。就像最后的评论一样。。。“你将失去战斗”我的诀窍是：存储库的根必须有pom。。。如果你启动一个模块（存储库顶部的文件夹），转换为多模块：）+1，只是为了说“如果你开始与Maven战斗，你将失去战斗”。悲伤，但这是真的。

[INFO] Executing goals 'deploy'...
[DEBUG] Using ${maven.home} of: '/usr/share/java/maven-3.0.3'.
[DEBUG] Executing: /bin/sh -c cd /Users/titan/.jenkins/jobs/jobB/workspace/Project-B/target/checkout && /usr/share/java/maven-3.0.3/bin/mvn -B -X -D maven.repo.local=/Users/titan/.m2/repository -s /Users/titan/.m2/settings.xml -D performRelease=true deploy