问题描述
正在开发一个自定义的Maven插件，用于生成一个以动态版本或构建号命名的zip文件构建产物。文件的格式类似于target/[artifactId]_[version or build].zip，其中[version or build]参数是基于时间快照（例如[changeset24]-[changeset57]）生成的，而构建的用户可能不知道最新的changeset。该插件使用一个API来确定最新的changeset，例如changeset57，并使用起始changeset参数来形成zip构建产物的唯一版本/构建号。
这个解决方案旨在简化我们企业在复杂架构中面临的基于增量的SQL脚本的混乱和手动过程。对于单个版本化的数据库构建产物，没有明确的环境升级路径。由于我们的DevOps组织非常不成熟，存在许多不兼容的框架和技能集，所以我将在这里省略其他细节。
最终，我们需要指定的不是这个构建产物的JAR文件上传到Artifactory，而是这里创建的ZIP文件。然而，Maven似乎不允许我们更改POM文件中硬编码的<version>，即使我们可以，我们也需要以下能力：
1. 使用自定义插件执行目标运行Maven构建。
2. 解析输出文件以获取生成的唯一版本号。
3. 覆盖Jenkins中的${VERSION}或${BUILD_NUMBER}环境变量。
4. 使用包含在构建信息中的新环境变量的版本或构建号将构建产物上传到Artifactory。
我的问题是，我似乎无法弄清楚如何使用现有的Maven3-Artifactory Jenkins插件或使用FileSpec JSON的通用Artifactory插件来配置这4个步骤，也不知道如何在这个过程中注入自定义shell脚本来覆盖环境变量。
有人有任何好的建议，我应该如何配置这个任务？
注意：请不要建议我的一般方法在根本上是错误的或有缺陷的。这并没有帮助，因为我面临着许多技术和政治上的限制，无法采用更合适的解决方案。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
根据用户的需求，我们可以通过以下步骤来配置Jenkins任务：
1. 在Jenkins任务中，添加Maven3-Artifactory插件，并配置构建环境，不上传任何构建产物到Artifactory。
2. 添加Generic Artifactory插件，用于将Maven插件生成的zip构建产物上传到Artifactory仓库。在插件配置中，使用Legacy Patterns选项来定义上传的构建产物和仓库位置，基于已经为您预先定义的一些环境变量（关于这些环境变量的更多信息将在后续步骤中提供）。下载详情部分保持为空。
3. 第一个构建步骤是执行Maven构建。
4. 第二个构建步骤是执行一个自定义的shell脚本，用于解析Maven构建产物的zip文件，获取所需的版本号，并将该版本号注入到作业工作空间根目录下的临时属性文件中。
5. 第三个构建步骤使用Inject Environment Variables插件，将临时属性文件中的内容注入到Generic Artifactory插件Legacy Pattern中使用的环境变量中。
这个解决方案在我的情况下似乎工作得很好。
方案2
如果方案1无法满足您的需求，您可以尝试使用Jenkins Pipeline来实现更复杂的构建流程。Jenkins Pipeline允许您以代码的方式定义构建过程，并且具有更高的灵活性和可扩展性。您可以使用Groovy语言编写Pipeline脚本，以实现自定义的构建逻辑和环境变量的处理。您可以在Jenkins的Pipeline文档中找到更多关于如何使用Pipeline的信息。
这是两种可能的解决方案，您可以根据您的具体需求选择其中之一。希望对您有所帮助！