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