4
据我所知，这是违反maven最佳做法，但也许我的情况是规则中少数例外之一 - 至少我坚持考虑替代方案:(如何从一个来源生成多个Maven构件
环境是这样的：
- 我们的专有技术为基础的界面的遗留应用程序向外界
- 我们要立足于原有的接口，我们生成Flash上使用闪存作为新的前端
- CL评估并将它们打包在一个flash swc中供前端开发人员使用
- 基于传统接口，我们生成了将Flash服务请求（经由blazeds）连接到我们的传统接口
- 以使其更加困难，我们不希望/不能在每个接口上使用它自己的pom，因为我们有几十个（接口），它们只会在它们的artifactId上有所不同。相反，我使用了一个“通用”项目结构，它将为每个构建（通过jenkins）进行参数化。该项目将只有被用于一个完全自动化的环境。
首先，我试图把所有这些放在一个“简单”的项目中，这个项目一直工作到工件应该安装的地步。
我目前的做法是行家参考第13章，其中有它自己的一些缺点，激发一个多模块项目结构：
GenericProject
|
+-- GenerateSources from legacy interface
| +-- pom.xml
|
+-- Java
| +-- pom.xml
|
+-- SWC
| +-- pom.xml
|
+-- pom.xml
这种方法有一个缺点，那我有“的Java” &“引用SWC“改为”GenerateSource“的内部结构，这是丑陋但可以容忍的。
我的方式真正得到的是，我必须严格调整安装&部署插件，以获得触发整个过程的名称&版本的传统界面的工件。 我现在运行了，但看起来非常脆弱。
我认为拆分/两个简单的项目复制项目：
- GenerateSources &的Java
- GenerateSources & SWC
但是这只能解决交叉引用的小麻烦。
正如亚伦在他的评论中指出的，我不清楚这个问题。 一些实验在这之后得到了很多更清晰的对我说： 基本上我有两个问题要解决
- 安装/部署两个文物一起
- 名比
project.artifactId
任何建议，使整个过程更像maven样？
在此先感谢。
我认为你应该把问题分解为更简单更具体的问题。现在，我不确定你的问题是什么。你知道关于允许在构建过程中创建更多构件的JAR插件吗？您是否知道指定最终工件名称的选项？ “内部结构的参考”究竟是什么意思？ – 2011-04-14 09:17:43
Hi Aaron，在我的单项目方法中，我已经将project.build.finalName设置为“$ {Interface-Name} - $ {Interface-Verion}”和 – Thomas 2011-04-14 10:07:22
[soory，wong key]。 。 。它得到了JAR插件的支持，所以我得到了一个“Interface-Name-Interface-Version.jar”。但是，安装和部署插件坚持使用project.artifactId来实现其目的。另外，快照和发布版本之间的区别也基于project.version而不是$ {Interface-Version}，因为我需要它。 – Thomas 2011-04-14 10:17:17