无需标记或编译的Maven版本 [英] Maven Release Without Tagging or Compiling

问题描述

我正在尝试使用Maven来构建JNI项目，并且在创建GA版本时遇到了一些困难.由于本机代码的要求，该项目的本机代码至少需要在3个系统(Linux，OSX，Windows)上进行编译.我还希望GitHub Actions在GitHub上创建标签时产生一个发布版本.因此，maven版本插件面临许多问题.看来，maven的发布过程涉及编译和测试代码，以及在创建GA版本和发布之前搞砸了SCM.对于此JNI项目，这根本是不可能的.我已经走过了与Ant的交叉编译器之路，出于各种原因，尤其是与苹果相关，我真的很想摆脱这种情况.我还考虑过分别释放每个JNI目标，但是我真的想将本机代码捆绑到JAR中，当我需要在不同的构建环境中共享.m2文件夹时，事情开始变得复杂起来.是否可以在没有所有编译，测试和SCM废话的情况下发布Maven项目?也许是另一个第三方插件?我应该有更好的方法吗?作为参考，可以在此处找到pom.

I am trying to use maven to build a JNI project and I am running into some difficulty creating a GA release. The project's native code needs to be compiled on at least 3 systems (Linux, OSX, Windows) due to the native code requirements. I would also like GitHub Actions to produce a release build when I create a tag on GitHub. Because of this, I am facing a number of issues with the maven release plugin. It seems like maven's release process involves compiling and testing the code as well as screwing around with SCM before I can create a GA version and release. This simply isn't possible for this JNI project. I have already gone down the cross compiler route with Ant and I would really like to move away from that for any number of reasons, mostly Apple related. I also thought about releasing each JNI target individually, but I would really like to bundle the native code inside of the JAR and things start getting complicated when I need to share a .m2 folder across different build environments. Is it possible to release a maven project without all the compiling, testing and SCM nonsense? Maybe a different 3rd party plugin? Is there a better way I should be doing this? For reference, the pom can be found here.

推荐答案

不要使用发布插件，通过

Dont use the release plugin, I had a lot more success with the maven version plugin.

所有maven版本插件所做的就是从快照中删除该版本，创建一个新的提交，然后将该版本升级到一个新的递增的SNAPSHOT.您可以模仿此过程，而无需Maven不需要了解使用版本的SCM的任何知识.

All the maven release plugin is doing is taking the version off the snapshot, creating a new commit and then upping the version to a new incremented SNAPSHOT. You can mimic this process without maven needing to know anything about your SCM using versions.

一种方法是不使用SNAPSHOTS而是使用git short哈希作为版本的一部分进行构建:

One way to do it is to not SNAPSHOTS and instead build with the git short hash as part of the version:

因此，在开发过程中，该版本看起来很正常

So while developing, the version looks pretty normal

    <groupId>org.example</groupId>
    <artifactId>my-app</artifactId>
    <version>1.1.0</version>

根据标签执行发布"构建.我的流量是

The do a "release" build based on a tag. My flow was

• 提交并推送
• 内部版本-mvn clean install，结果为my-app-1.1.0.jar
• 部署到测试环境并运行回归测试，如果测试成功，我们将使用"passed_tests"标记来标记提交
• CI在与"passed_tests"匹配的标签上触发-这需要与导致受测试的jar相同的提交
  • 运行mvn -f ./pom.xml versions:set -DnewVersion=${gitProps['git.build.version']}_${gitProps['git.commit.id.abbrev']} 在磁盘上，我们的Maven版本现在为:
  • commit and push
  • build - mvn clean install, results in my-app-1.1.0.jar
  • deploy to a test env and run regression tests, if they succeed, we tag the commit with a "passed_tests" tag
  • CI fires on tags that match "passed_tests" - this needed to be the same commit that resulted in the jar under test
    • runs mvn -f ./pom.xml versions:set -DnewVersion=${gitProps['git.build.version']}_${gitProps['git.commit.id.abbrev']} On the disk, our maven version is now:

        <groupId>org.example</groupId>
        <artifactId>my-app</artifactId>
        <version>1.1.0-abcdef</version>
    

    • 然后运行mvn deploy.这是被部署到仓库的工件，现在我们有了一个jar文件(或其他文件)，其版本与git commit匹配.
    • then runs mvn deploy. This is the artifact that gets deployed to the repo and now we have a jar file (or whatever) that has a version matching the git commit.

    您可以对所有目标体系结构使用相同的过程.

    You could use the same process for all your target architectures.

    这篇关于无需标记或编译的Maven版本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！