故事是這樣的，專案的 project 海當中有一個是處理 Applet（不要問為什麼這個年代還在用 Applet，我後來改了一個 JWS 的版本，但是客戶還是想要保留 Applet [攤手]）。雖然這個 project 是 maven 結構，但是 sign jar 還有最後整合進去真正的 web project 都還是用人工手動作的（不要再問了，我都要落淚了）。
雖然千百個不願意碰這個 Applet project，但事情終究還是發生了，因為最底層的 library 升級了，所以不改不行，那就順便把他變得自動化一點吧… Orz
sign jar 當然是找 maven-jarsigner-plugin（以下簡稱 jarsigner），掛上去之後發現… 奇怪，怎麼始終 build 失敗？用他錯誤訊息噴出來的那個 Windows command 字串去執行看看（當然要把 keypass 跟 storepass 換回實際的字串）卻又沒問題。喔對了，似乎這個問題只會在 Windows 上頭重現… Orz
最後發現，問題不是出在 jarsigner 上，而是 project 當中本來就有掛的 maven-assembly-plugin（以下簡稱 assembly）造成的。因為如果拿掉 assembly 的設定、或是把 jarsigner 挪到 assembly 之前（這居然是某些人認為的解法… 完全沒意義阿… WTF），是可以正常運作的。
兩個 plugin 的官方 issue tracker 都有這件事情（jarsigner、assembly）。似乎是 assembly 2.2 版之後才會發生的事情，因為退回到 2.1 版就沒問題了，那就退回去吧… 祈禱不要踩到「為什麼要升級」的哏。
BUT…
希望 assembly 產生的檔名是乾淨的 foo.jar，所以加了 <finalName>、也加了 <appendAssemblyId>false</appendAssemblyId>，然後又開始 build 失敗了。問題點是卡在 <appendAssemblyId> 上頭。最妙的事情是… 這個問題在 2.2 之後解決了…
…………（嗶──）
好了，解法有兩個，一個是忘記 assembly 改成用 maven-shade-plugin，我用 2.0 版測試沒有問題，能滿足上述兩個需求。
另一個是… 把 assembly 提升到 2.6，也可以滿足上述兩個需求… （我沒有測 assembly 2.5 搭配 jarsigner 會不會出問題，但是 2.4 版是確定有問題的）
…………（嗶──）
我說那個 issue 可以麻煩順便關一關嗎？還是說根本是不知不覺間修好了，所以也沒發現......
這種排列組合的問題實在是很浪費生命阿… [淚目]
