プラグイン作って覚えたことを淡々と記録するよ(PathManager編)
個人的には今更感が漂う話なんだけど...。IDEAの設定情報なんかを保存しているディレクトリは,
$HOME/.IntelliJIdea70
ってディレクトリで,さらに目的別にこんな風に分類されているワケだ。
$HOME/.IntelliJIdea70/ |- config/ ... File -> Settingsで設定した各種設定情報が保存してある | : | |- plugins/ ... プラグインの保存先 | | |- IdeaVim/ ... プラグイン毎にディレクトリが出来る(Jarだけってのもある) | : : |- system/ ... ローカル履歴とかJarキャッシュとかワーキングっぽい情報が保存してある :
ちなみにこれ,OSXだと構成が違ってて,pluginsディレクトリだけが$HOME/Library/Application Support/IntelliJIdea70
になってたりする(他のディレクトリの場所は忘れた)。
で・だ。プラグインディレクトリなんだけど,プラグインを更新すると,今あるディレクトリを更新するんじゃなくて,一旦消してから上書きするっていうのを最近知ったのだ。
要は,WinstoneプラグインでWinstone本体やCommonLibsの置き場を,自身のプラグインディレクトリ...
$HOME/.IntelliJIdea70/config/plugins/winstone-plugin/
に置くことを推奨してたんだけど,あまりよろしくなかったなって話だ。:-P
#アップデートのたびに消されちゃ叶わん。
そんなわけで,pluginsディレクトリ以外の,これら規定ディレクトリのパスを取得する方法を調べてみたよって話。といっても全然難しくもなく,ちゃんとAPIリファレンス読んでなかっただろってのを暴露する話なのだ。:-D
そもそも,Winstoneプラグインで,自分自身が格納される場所をどうやって知っているかっていうと,こんなコードで知り得ていたワケよ。
public String COMMONLIB_DIRECTORY = PathManager.getPluginsPath() + File.separator + "winstone-plugin" + File.separator + "commonLibs";
PathManager.getPluginsPath()
...ああ,なんてわかりやすい。この流れで,PathManagerの他のAPIを探ると,あっさり解決。
$HOME/.IntelliJIdea70/ |- config/ -> PathManager.getConfigPath() | : | |- plugins/ -> PathManager.getPluginsPath() | | |- IdeaVim/ | : : |- system/ -> PathManager.getSystemPath() :
あとは,これらディレクトリの使い方なんだけど,実はあまりハッキリしてない。「pluginsディレクトリに変更する可能性のある情報を置いてはイカン」ってのはハッキリしてんだけどね。余所のプラグインを見ると,あるものは configディレクトリ下に独自のディレクトリ切ったり,あるものはsystemディレクトリk下だったりと,イマイチ一貫性に欠ける。
あれこれ見た結果,svn4ideaプラグインが採用していた場所が,まあまあしっくり来るので,今後そうゆう用途があれば,ここを利用しようと思う。
#...Winstoneプラグインは,もう今さらだから対応しない。:-P
んで「ここ」ってどこよ?というと,ここ(↓)。
$HOME/.IntelliJIdea70/ |- config/ |- system/ : |- plugins/ --> ここを各種プラグインのワーキング領域にする。 : |- pluginName/ <-- たとえば,こんな感じ
プラグイン作って覚えたことを淡々と記録するよ(GeneralCommandLine編)
まあ,いわゆるひとつの外部プロセスの起動方法ですな。
これも,今さらネタ。DerbyプラグインがIDEAと同一VMで動くためPerm領域を圧迫する問題があったんで,外部プロセス化してみ...るくらいだったら,External ToolsにDerbyの起動シェル登録するわ!!以上,おしまい。:-)
っていう話もあるけど,それじゃ身も蓋もないんで,一応外部プロセスの起動方法だけでもメモっとく。見ての通り,すげー簡単。
private void start() throws Exception { GeneralCommandLine cmd = new GeneralCommandLine(); cmd.setExePath("c:/javadb/bin/startNetworkServer.bat"); Process process = cmd.createProcess(); LOGGER.info("derby start"); }
GeneralCommandLine.createProcess()で得たProcessの出力情報をConsoleViewに流したりもできるっぽいけど,DerbyプラグインはApplicationComponentってこともあり面倒臭いからやらんかった。
#ConsoleViewを取得するには,Projectインスタンスが要るのだ。
#さらに加えとくと,ConsoleViewはTextConsoleBuilderから,TextConsoleBuilderはTextConsoleBuilderFactoryから取得する。
ちなみに,Derbyプラグインについてだけど,もともとが無設定でポチっと使える俺様プラグインだったワケなんで,わざわざ面倒なことをしてまでGeneralCommandLine化するつもりはないよ。
ただ,GeneralCommandLine化すると対象がDerbyである必要もなくなるワケで,もっかしたら「ON/OFFできるボタンをツールバーに置くだけプラグイン」として生まれ変わるかも知れない。:-P
なんというコミュニケーションツール
ここ最近,自社からのアクセスより,前の常駐先からのアクセスが多くなったヨ。
#常駐終わって自社に戻ってきたにも関わらず。
はてダ,なんというコミュニケーションツール。
セールスツールにならないのが玉に瑕だ。:-P