VisualStudioCode で 「Building workspace」とか「Compile」がいつまで経っても終わらない現象。あるいは異常に時間がかかる。

 

 結論だけ見たいって人は、「◆見つけた回避策」までスキップ。

 

◆前置き

 推し事 お仕事では、JavaでWEBアプリケーションの開発を行っている部隊に所属している私です。これまでは、関連会社間で標準として定められた、プラグインマシマシ過ぎのEclipseを使っていたのですが、これが資産管理系のツールやら社内ネットワークやらと大変に相性が悪く、頻繁に固まる(落ちる)ような環境でして……。そんな環境での開発を強いられていました。
 変数コピーしようとして選択状態にしたり、コード打ち込んだり、ファイル切り替えたり……そんな些細なことで、固まりやがるのですよ。ストレスで寿命がマッハです。

 そんなある日、いつも通り応答なしになったEclipseさんを放置しながらネットを見ていたところ、VisualStudioCodeでJava開発環境を整える、という記事がたまたま目に入りました。完全に思いつきて、ものは試しにと使い始めてみたところ、これがとても快適でめっちゃ気に入ってしまい、上司らとの色々な交渉の末にこっちをメインの開発環境に切り替えられることになりました。

 これでEclipseから解放されるぞ、と喜んでいたのですがしかし、そこで遭遇したのが、この表題の現象。

image

 この写真にある「Building workspace – 0%」が点滅を繰り返し、ずっと終わらんのです。
(警告数とか、他の情報は気にしないでください、撮影のために色々したやつなので。本件とは関係ありません。キャプチャではなく写真なあたりも、察して!)

 これが終わらないせいで、いつまで経ってもデバッグ実行が出来ず、また定義情報の参照なども出来ず、Javadocは表示されずF12を押しても定義に飛べず、といった感じで、このままでは開発に支障が出てしまう状態でした。
 ネットで調べても同様の現象に引っかかっている人はあまりおらず、Githubのコメント欄に海外の人で似たような人が何人かいた程度でした。(そしてその人達も未解決っぽい?)

 厳密には、待ってればちゃんとビルドは終わるんです。2時間くらい待てばですが
 一度終わってしまえば、そのあとはしばらく平和な状態になり、ソース書き換えたりしてもちゃんとすぐ反映されるし、その際の自動ビルドもすぐ終わってるんです。しかし何かがトリガーになるようで、いきなりまた現象が再発する、という状態でした……。

 この現象に、かれこれ2か月ほど悩まされてきていました。それでもVisualStudioCodeを使い続けて、色々と試行錯誤してました。(こんな状態でも、弊社のEclipse使い続けるよりマシだったので)
 そして先日ついに! この現象を回避する方法を特定したので、情報共有も兼ねて、ここに記事として残しておきたいと思います。同じ問題で悩まされてる人に少しでも参考になれば……と思いますが……。(ただ、うちの場合は環境が変だったことに依存してそうなため、あまり参考にはならないかもしれません)

 というわけで、次からが本題。

 

◆環境

 まず、使用OSやVScodeのバージョン、主な拡張機能等を整理します。

Windows 7 SP1(現象発生時点での最新のWinUpd適用済)
Visual Studio Code 1.30.1(user setup)
 ・Java Extension Pack
 ・Spring Boot Extension Pack
 ・Lombok Annotations Support for VSCode
Spring Boot 1.5.12
PostgreSQL 10.5
Gradle使用(version 2.6)
バージョン管理:Subversion 1.9..以下省略 (クライアント側はTortoiseSVNを使用)

 主だったところはこんな感じ。VScodeでJava(+ Spring boot)開発をやるって場合のごくありふれた構成です。強いて上げるとするなら、Gradleが大分古い(2.6)ことやバージョン管理がGitではなくSubversionってところがレトロな感じですね。これでも少し前までバージョン管理使ってなかった状況からは大分改善されてるんだぜ……?

 バージョンはともかく、Subversionのディレクトリ構成が少し変わってるので、下図に提示します。

・branches
  –各ブランチ(省略)
・tags
  –各tags(省略)
・trunk
  –ドキュメント類(省略)
・src
  –各プロジェクトのソース類
  |-project_a
  |-project_b

 こんな感じの構成です。
 trunkではなく、別途「src」というソース管理専用のディレクトリを作って、その中で開発を行っていました。ちなみにこの構成を決めたのは前任者(退職済)なので、どうしてこういう構造にしたのか、その理由は誰も知りません。コワイ!

 ここでは、現象の起きている対象のプロジェクトを「project_a」という名前に仮定して話を進めます。

 

◆調査経緯

 さて。
 わざわざ「Subversion」の構造を挙げたので勘のいい方はお気づきかもしれませんが、今回の事象の原因にはこれがか関わってきます。めっちゃ重要です。しかしその、構成がちょっとアレなのと再現確認が不十分なので、あまり自信はないのですが……。
 それはそれとして、私はこの件に関しては、以下のような経緯で調査してました。

 まず、この環境は一応自分が管理者となっていることもあって、TortoiseSVNを使って全ディレクトリをローカルにチェックアウトして使っておりました。VScodeでは、このチェックアウトしたディレクトリの中にある src/project_a を開いて開発を行おうとしており、その際にこの現象が発生していました。
 拡張機能やVScodeのログ確認、ワークスペースフォルダやキャッシュフォルダのクリア、VScodeの再インストール、System Setup版への変更や、前回記事のような改造CSSをやめるなど、色々やりましたが全く解決せず。その後も色々調べていたところ、この現象、部内で私だけでなく複数人で発生しており、しかしその一方で現象が発生しない人もいることがわかりました。何人かに協力を仰いで調査したところ、以下のことが判明しました。

・現象が起きない人は、今まで一度も起きていない
・現象が起きる人は、ほぼ確実に発生する
・OSやVScodeのバージョンは関係なさそう?(混在してたので)
・上記拡張機能以外は、各自自由な状態
現象が起きる人のPCでも、branchesに置いたソースならば現象が発生しない
もう一つの「project_b」では現象が発生しない

 下2つがかなり気になりますね。ここら辺を重点的に見てみることにしました。

 まずは「project_b」ですが、これはproject_aと比べると圧倒的に小さいプロジェクトです。ソースのファイル数も10個程度しかないもので、こいつは基本的に「project_a」の補助ツール的なものでした。こちらをVScodeで開いても、特に現象は発生しておりません。一方で、「project_a」はソースファイル、JSやHTMLなどのリソースも含めると数千ファイルあるような規模です。
 次にbranchesのほうですが、ここには project_a の専用カスタマイズを行う場合のソースが、srcからブランチを切って格納されています。なので基本的に規模としては「src」の中にあるものと大差ありません。ですが、こちらのソースをいくつかVScodeで開いてみたのですが、なんと全く現象が起きないではありませんか!

 個の段階で一先ずメンバーには、srcからbranchesのほうに新しくブランチを切って、当面の間、メインの開発環境をそっちに移動してもらい、私だけがsrcに残って調査を続けることになりました。そしてそこからさらに数日……ついに現象の回避策を見つけるに至ったのです!

 

◆見つけた回避策

 Subversionでチェックアウト済みの「project_a」を、別のディレクトリに直接チェックアウトしなおして、そこを開く。

 

 以上。

 

 終わり!

 

 閉廷!!!!!

 

 いや、本当にこれだけだったんです。

 例えば、「C:\svn」ってディレクトリに全部チェックアウトしていたとすると、これまでは「C:\svn\src\project_a」を開いていたのですが、これをやめて「C:\svn_src_pj_a」というディレクトリに /src/project_a だけをチェックアウトして、これを開くようにした。こう変えただけで、まったく現象が発生しなくなりました。うっそだろお前、と叫んでしまったのも無理ない話です。

 私だけの環境かもしれない、と思ったのですが、これを他の人にも試してみてもらったところ、全員が解決しました。お前マジかよお前ェー!

 

◆推察

 ここからは推察というかただの妄想ですが、何故、これだけで現象が回避できたのでしょうか。
 VScodeはバージョン管理との連携機能を備えていますが、これはGitにしか対応しておらず、Subversionは対応しておりません。しかし、どこかで見かけたのですが、Subversionのチェックアウトしたときに作成される「.svc」のディレクトリがある場合にはそれを無視するよう設定する、的な記述を見た覚えがあるのです。もしそれが自分の記憶違いでないなら、VScodeはSubversionに非対応だとしても、Subversionそのものについては何かしら認識しているのかもしれません。

 そうなると、Subversionでは一般的ではない(かもしれない)ディレクトリ構造でのソースフォルダで、ソースを開いていたことが、裏側で何か予期せぬ動作を引き起こしていたのかもしれません。branchesディレクトリのほうなら何も問題が無かったというのも、そこらへんが理由なのかな?と。
 ちなみにproject_bについては単に、現象が起きているものの規模が小さすぎてbuild時間が伸びていることに気付けてないだけなのでは?という予想しています。

 ちなみに、別フォルダにあらためてリポジトリ全部まるごとチェックアウトしなおしてproject_aを開いてみましたが、現象が再現しました。やっぱり構造の問題なのでしょうか……?

 

 推察部分に関しては完全に未検証ですし、これといった根拠もあるわけではないので、素っ頓狂なことを言っている可能性もあります。しかしいずれにせよ、もし同現象で悩まれている方は、一度別ディレクトリにソースフォルダをチェックアウトしなおす、という手段を、是非一度お試ししてみてもらいたいものです。

Visual Studio Code のデバッグコンソールとかに背景画像を設定したい

 

 メリークリスマスを通り越して、気が付けば大晦日も大晦日。みなさん如何お過ごしでしょうか。僕はAqoursの紅白出場が見れたので満足しているところです。

 

 で、ふと、そうおいえば12月はまだブログ更新してなかったことを思い出して、今あわてて書いているところです。別にノルマとか無いんですけども。というわけでタイトルの通りです。

 本題。エディタとかに背景画像を設定するのは、ぐぐればすぐ出てくるので簡単に出来てるんですよ。主に幻想ツバメさんとこの記事を参考にさせてもらいまして。要はCSSいじってあれこれ弄っちゃうってわけですね。これによって、こんな感じにするところまではあっさり出来ました。

image

 

 

 そこまでは良かったんですが、エディタやターミナルは画像設定できてもデバッグコンソールとかのタブが出来なかったんですよね。(ターミナルと共通だと思ってた)

 

image

 

 

 これがググってもどう書けばいいのか出てこなかったので、自分で適当に調べて、設定してみました。のでそれ晒しときます。ただ、ぶっちゃけCSSとか全然詳しくないので、なんか変な書き方してたらゴメンナサイね、適宜修正して使ってください。(もちろん自己責任でお願いします)

 

 ヘルプの開発者ツールから適当に要素を調べた感じ、デバッグコンソールの要素名はpanelみたいなので、「 workbench.main.css 」に以下を書き加えてみました。

.monaco-workbench .part.panel {
    background: url("///C:/MyData/vscode_custom/panel.jpg") no-repeat;
    background-position: right top; 
    background-size: contain;
}

 

 したらばこんな感じで、デバッグコンソールにも画像を設定できました。

image

 

 細かい調整とかは必要ですが、ひとまず画像設定するだけならこれで……。誰かの役に立てば幸いです。

 

 

 それではみなさん、よいお年を。