hudson-cliの仕組みが，もっと分かって来た

川口さん，解説ありがとうございます。なるほどCLIそのものがスタブだったのですね。
→ Hudson CLIの内部構造 - 川口耕介のブログ

そんでもって，ここ（↓）

サーバ側からは折り返しCLI側へクロージャを送って実行することも出来るので、当然ローカルからリモートへのファイルコピーや、あるいはもっと複雑なことも出来ます。

を試してみるべく，いろいろいじくってみた。結論としては思惑通りに行かなかったんだけど，だいたいの仕組みがわかったのでよしとする。
いちいち言う事じゃないけど，川口さんSUGEEEE!!

試してみたのは"サーバから折り返して送信するCLI側クロージャ"。ちょうどGroovyCommandという，そのものズバリなコードを見つけたので，すぐ分かった。このGroovyCommand，Hudson v1.304には含まれていないけど，多分こんなふう（↓）にして，CLI側にあるスクリプトファイルをサーバで実行させんだと思う。
＃まあステキ，知りたかった事が一発でわかったわ。:-)

$ java -jar hudson-cli.jar -s http://localhost:8080/ groovy hoge-script.groovy

ポイントは59行目のloadScript()メソッド，ここのChannel.call()に与えているコールバックハンドラ（Callable）が，くだんのCLI側クロージャってやつですな。
で，喜び勇んでこんなコード実行してみたんだけど，うまく行かんかった。:-(

むむぅ，クロージャをas演算子で強制的にCallableに変換するんじゃダメか。気を取り直して，こんなコードにしてみたけど，やっぱりダメだった。orz

まあ，hudson.warにクラスファイルが納められてるCLICommandの子どもと，そのひとつであるGroovyshCommand内でon-the-flyで作ったコードとじゃコンテキストが違うから，動かないのも分からんでも無いよ。
でもさ，CLICommandの子どもを作らなくても，既存のgroovyshから

Channel.current().call { /* CLIで動いてほしいコード */ }

みたいにできたらステキだよね。:-)

ps.
そうそう，hudson-cli.jarの中身をみてみると分かるんだけど，ご覧のとおりCLICommandは含まれてないんだよね。

だからgroovyshがむこう（サーバ側）で動いてるってのはわかる。それだけに groovy(GroovyCommand)がCLI側で動いたらすげーびっくりすると思う。

やっぱり大事な事なので２回言います。
川口さんSUGEEEE!!!!!