動く時は動くけど、
動かなくなると、
トコトン動かなくなるのがMaven。
気のせいかもしれないが、Maven処理が始まるとどこかに通信しているようだ。
インターネット接続が重い会社はたくさんあるから案外同様の事態になっているかもしれない。
だがMavenはローカルにリポジトリィを作成しているのでここに繋がるのに時間がかかっているのならやはりPCスペックが貧弱すぎるのかもしれない。
とは云え、
ビルド対象が莫大な数になると
当たり前と云わんばかりに重くなるのはAntと変わらない。
このあたりがやはり馬鹿プロジェクトっぷりが凄い。
処理の高速化や正確さをアルゴリズムに求めるのはもっともだが、IN・OUTのタイムスタンプぐらい使ってもいいような気がする。
※もっともsvnでrevertすることを考えると、svnがタイムスタンプを調整してくれないとどうしようも無い。ただ、svnの調整しようとは考えず、タイムスタンプを使わず、毎度毎度、延々と長時間かけて全部ビルドし直すしかないのも変な話だ。
これではEclipseでソースを保存すると自動ビルドが始まる場合、
ビルドに数分間もかかりので、保存する度に数分間待ち、良くても「保存」がロックされてしまうし、大抵は「処理中の画面」が邪魔で何も操作はできなくなってしまう。
これでは、２～３個のファイルをちょっと手直しするにもバカバカしくいくらい時間がかかってしまう。
致命的なのはJUnitの起動時間も重くなってしまうこと。
そう、JUnitは、JUnit用にビルドしなおしてからテストを開始する仕組みなので、
ビルド時間が長い仕組みになっているプロジェクトファイルは致命的。
この様な状況にならなくするには
リポジトリィをローカルとプロジェクトに分けて
ローカルにはデバッグに最低限必要なものに抑えておく以外に方法は無い。
ただSubcliptでそれをやってしまうと、なにげにコミットしてしまうと、不要なので消したファイルの削除情報もコミットされかねないので恐ろしい。
だからコミットは１ファイルづつ慎重に慎重に慎重に慎重に慎重に慎重に慎重に慎重に
阿保クサ。
んーなもん作った奴は ソースは１００も無いものばかり作ってるか Gitでも使ってるんだろうなぁ・・・
Eclipseといい、Subclipse、Mavenといい、物量に弱すぎる。
これなら make ＋ javac ＋ ☆丸 スタイルの方がデバッグは一万倍スムーズじゃないのかな？
もっともソースレベルデバッガが無いと苦しいけどね。
どうやらJava開発には最高のPCスペック（最高のCPUと最高のSSDといっぱいのメモリに６４ビット版のOS）が必須条件になったようだ。
本当に馬鹿な話だ。