我知道这违反了 maven 最佳实践，但也许我的情况是规则中为数不多的异常(exception)之一——至少我一直在思考替代方案:(

环境是这样的:

我们有一个遗留应用程序，该应用程序具有基于专有技术的外部接口(interface)

我们想使用 flash 作为新的前端

基于遗留接口(interface)，我们生成 flash 类并将它们打包到 flash swc 中以供前端开发人员使用

基于遗留接口(interface)，我们生成将 flash 服务请求(来自 blazeds)连接到遗留接口(interface)

的 java 类

为了让它变得更加困难，我们不想/不能为每个接口(interface)单独使用一个 pom，因为我们有几十个(接口(interface))，它们只会在它们的 artifactId 上有所不同。相反，我使用“通用”项目结构，它将为每个构建(由 Jenkins )参数化。该项目将仅在完全自动化的环境中使用。

首先，我尝试将所有这些都放在一个“简单”的项目中，该项目一直到应该安装 Artifact 的地步。

我目前的方法是受 maven 引用第 13 章启发的多模块项目结构，它本身有一些缺点:

GenericProject 
| 
+-- GenerateSources from legacy interface 
|   +-- pom.xml 
| 
+-- Java  
|   +-- pom.xml 
| 
+-- SWC  
|   +-- pom.xml 
| 
+-- pom.xml 

这种方法有一个缺点，我从“Java”和“SWC”引用了“GenerateSource”的内部结构，这很丑但可以容忍。
真正阻碍我的事情是我必须对安装和部署插件进行大量调整，以获取具有触发整个过程的遗留界面的名称和版本的 Artifact 。
我现在让它运行，但它看起来很脆弱。

我考虑在两个简单的项目中拆分/复制项目:

GenerateSources 和 Java

生成源和 SWC

但这只会解决交叉引用的小麻烦。

正如 Aaron 在他的评论中指出的那样，我不清楚说明这个问题。
经过更多的实验，这对我来说更清楚了:
本质上我有两个问题要解决

一起安装/部署两个 Artifact

将 Artifact 命名为不同于 project.artifactId

有什么建议可以让整个过程更像 Maven 吗？

提前致谢。

请您参考如下方法:

在使用多模块方法走了一些弯路之后，我得出了以下实用的解决方案:

使用 build-helper-plugin附加要自动安装/部署的辅助 Artifact

两阶段构建:

2.1 通过sed 生成pom.xml其中包含已解析的 project.artifactId & project.version
2.2 运行maven构建

虽然理论上您可以将表达式用作 project.artifactId & project.version , maven 给你一个警告。 . .有一个很好的理由:
当您尝试引用生成的 Artifact 时，nexus 会给您一个“无法读取 Artifact 描述符......”错误。
我怀疑这是因为在存储库中存储的 pom 中，表达式未解析!