⇧ 断熱材の性能が上がるということは、
⇧ いよいよ、日本の家屋が改善されると考えて良いんですかね。
Jetpack.ioのDevboxで開発環境を構築する前にDevboxでできることを確認
Devboxでどんなことができるのか確認してみますか。
一応、公式のドキュメントによりますと、
⇧ Devboxをインストールすると使えるようになる、devboxコマンドで環境を構築していく模様。
おそらく、Devbox自体のバージョンを管理するような方法は無さそうね...
つまり、Node.jsのバージョンを管理するnvm（node version manager）的なものは無さそう...
⇧ なるほど、Devboxプロジェクトの環境についてはバージョンを統一するしかないってことですかね。
Devbox自体のバージョンをアップグレードせざるを得なくなった場合に、旧バージョンとの後方互換性は担保してくれるということなんだろうか？
検証のために、Devbox自体のバージョン管理ができるようになっていれば便利な気がしたんですが...
手動でバージョン切り替えはできるっぽいけど...
ちなみに、
⇧ devbox createコマンドでテンプレートからDevboxプロジェクトを作ることもできる模様、2024年2月5日（月）時点だと、サポートされてるテンプレートは多くなさそうだけど...
Devboxのビジョンとは乖離しそうだけど、
⇧ Dockerコンテナを利用することもできるってことかね。
一応、
⇧ パッケージとしてdockerはあるっぽいのだけど、Docker deamonが含まれてるのかが分からん...
ただ、DevboxってDockerのビルドに時間がかかり過ぎて辛いっていうモチベーションで開発されたっぽいから、Dockerを使うのはDevboxとしては本意では無さそうね...
その代わりに、
It is heavily inspired by docker-compose, but without the need for containers. The configuration syntax tries to follow the docker-compose specifications, with a few minor additions and lots of subtractions.
⇧ devbox serviceコマンドでDocker Composeのようなことが実現できると。
『It is heavily inspired by docker-compose』ってあるから、Dockerが与えた影響力は半端ないですな...
ただ、devbox serviceコマンドによる生成物に対して、docker exec のようにログインできるのかが分からん...
Jetpack.ioのDevboxで開発環境を作ってみるものの...
悲報...
⇧ 2024年2月5日（月）時点で、Devboxの環境に対応して無さそう...
何やら、
⇧「WSL 2（Windows Subsystem for Linux 2）」を使っていれば、VS Code（Visual Studio Code）でDevboxの環境と同期できるってことなんかね。
ザックリ、ドキュメントを確認した感じ、手順としては、
- Linux環境（WSL 2: Windows Subsystem for Linux 2）での作業
- Devboxをインストール（devboxコマンドが使えるように）
- Devboxのプロジェクト作成
- Devboxプロジェクト用のディレクトリ作成
- devbox initコマンドでDevboxプロジェクト作成
- ライブラリのインストール
- devbox add [ライブラリ]コマンドで開発に必要なライブラリをインストール
- devbox shellコマンドでDevboxプロジェクト環境を起動
- VS Code（Visual Studio Code）でDevboxプロジェクト環境へRemote SSH
みたいな感じになるんかな。
では、環境構築してみますか。
とりあえず、「WSL 2（Windows Subsystem for Linux 2）」のRocky Linuxを起動してログインしておきます。
まずは、ドキュメントの通り、Devboxをインストール。
curl -fsSL https://get.jetpack.io/devbox | bash
Devbox環境プロジェクト用のディレクトリを作成し、移動しておく。
mkdir -p [Devbox環境プロジェクト用のディレクトリ]
cd [Devbox環境プロジェクト用のディレクトリ]
ドキュメントの通り、Devboxプロジェクトとして初期化。これで、Devbox環境になる模様。
devbox init
ドキュメントの通り、Devboxプロジェクトの環境に接続。
devbox shell
⇧ このDevbox環境の中で、devbox addコマンドで開発に必要なパッケージを追加していく感じですかね？
で、Windows側で、VS Code（Visual Studio Code）を起動して、拡張機能のRemoteSSHで、「WSL 2（Windows Subsystem for Linux 2）」のRocky Linuxに作成したDevbox環境に接続していくと。
左下の 
のアイコンをクリック。
で、「Connect to WSL using Distro...」を選択し、
「WSL 2（Windows Subsystem for Linux 2）」のRocky Linuxに接続出来たら、「Open Folder」を選択。
で、Devbox環境のプロジェクトのディレクトリを選択し、「OK」押下。
Devbox環境のプロジェクトのディレクトリにアクセスできました。
そして、再びの悲報...
⇧ インストール可能なパッケージ一覧をコマンドから確認するのは厳しい模様...
どんなパッケージが利用できるか確認できないとか、開発させる気がないやん...
致し方無いので、
⇧ Devboxのドキュメントを参考に、決め打ちで利用するパッケージを指定するしか無さそう...
⇧ う～む、バージョンの組み合わせとかは特に気にしなくて良いってことなんかね？
そもそも、binutilsとか使ったことないからして、用途が分からん...
バージョンを指定して、パッケージをインストール。
devbox add jdk@21+35 binutils@2.40 gradle@8.5
⇧ やけに時間かかったけど...
一応、devbox.jsonに追加されてるっぽいのだけど、インストールされたってことで良いんかな？
Javaのバージョン確認してみたところ、
⇧ devbox addコマンドで追加したものがインストールされていそう。
Gradleでプロジェクトの初期化を行う。
勿論、みんな大好きのJavaを選択。
⇧ このあと、拡張機能で、「Gradle for Java」とかもインストールしてます。
で、ドキュメントの通り、gradle.propertiesファイルに$JAVA_HOMEの値を設定で。
で、何故か、Gradleのビルドで「> Task :app:test FAILED」となって、
■/home/ts0818/devbox/java-project/app/build/test-results/test/TEST-app.project.AppTest.xml
<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="Gradle Test Executor 13" tests="1" skipped="0" failures="1" errors="0" timestamp="2024-02-04T12:57:24" hostname="Toshinobu-PC" time="0.383">
<properties/>
<testcase name="failed to execute tests" classname="Gradle Test Executor 13" time="0.383">
<failure message="org.gradle.api.internal.tasks.testing.TestSuiteExecutionException: Could not execute test class 'java.project.AppTest'." type="org.gradle.api.internal.tasks.testing.TestSuiteExecutionException">org.gradle.api.internal.tasks.testing.TestSuiteExecutionException: Could not execute test class 'java.project.AppTest'.
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:54)
at java.base@21/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base@21/java.lang.reflect.Method.invoke(Method.java:580)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
at jdk.proxy1/jdk.proxy1.$Proxy2.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker$2.run(TestWorker.java:176)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.executeAndMaintainThreadName(TestWorker.java:129)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:100)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:60)
at org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:56)
at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:113)
at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:65)
at app//worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:69)
at app//worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:74)
Caused by: java.lang.SecurityException: Prohibited package name: java.project
at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:910)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1025)
at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:534)
at java.base/java.lang.Class.forName(Class.java:513)
at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.loadClass(JUnitPlatformTestClassProcessor.java:168)
at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.access$100(JUnitPlatformTestClassProcessor.java:62)
at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.execute(JUnitPlatformTestClassProcessor.java:104)
at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.execute(JUnitPlatformTestClassProcessor.java:94)
at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:60)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:52)
... 16 more
</failure>
</testcase>
<system-out><![CDATA[]]></system-out>
<system-err><![CDATA[]]></system-err>
</testsuite>
⇧ 確認したところ、エラーになっていて、
⇧ Javaのパッケージ名（拡張子が「.java」のファイルが配置されるまでのディレクトリ）が、禁止されているものになってしまっていたことが原因と...
予約語とバッティングしたみたいなものか...
■修正前
java/project
■修正後
app/project
⇧ にディレクトリをリネームして、.javaファイルのpackage文も修正したところ、エラーが解消されました。
で、今度は、Visual Studio CodeのGUIでの「Run Java」が失敗する...
エラー文言的に、Visual Studio Code側で利用するJDKを指定する設定をすべし、とのことで、プロジェクトのディレクトリ直下に、「.vscode/settings.json」を作成し設定。
.vscode/settings.jsonに設定を追加するも、効果なし...
{
"java.configuration.runtimes": [
{
"name": "JavaSE-21",
"path": "/nix/store/bn9dkyw8gandxvl1i09y3qmka10qa0ba-openjdk-21+35/lib/openjdk",
"default": true
}
]
,
"java.jdt.ls.java.home": "/nix/store/bn9dkyw8gandxvl1i09y3qmka10qa0ba-openjdk-21+35/lib/openjdk",
}
どうやら、「/root/.vscode-server」が異なるJDKを参照してしまっているのが原因らしく、
⇧ 上記サイト様を参考に、根こそぎ削除して、
Windows側のVS Code（Visual Studio Code）から「WSL 2（Windows Subsystem for Linux 2）」のRocky Linuxへリモート接続し直して、拡張機能をインストールし直して、
ようやっと、動いた...
最終的に、.vscode/settings.jsonは、以下の設定になっていた。何か、GUI上で出てきたダイアログの選択とかも影響してそう。
{
"java.configuration.runtimes": [
{
"name": "JavaSE-21",
"path": "/nix/store/bn9dkyw8gandxvl1i09y3qmka10qa0ba-openjdk-21+35/lib/openjdk",
"default": true
}
]
,
"java.jdt.ls.java.home": "/nix/store/bn9dkyw8gandxvl1i09y3qmka10qa0ba-openjdk-21+35/lib/openjdk",
"java.compile.nullAnalysis.mode": "automatic"
}
う～む、Devbox環境自体は分離されてるのかもしらんけど、結局、VS Code（Visual Studio Code）とかが足を引っ張ている感じで、環境依存しまくるね...
後、何か、速度がそんなに早いと感じられなかったんだけど...特にパッケージのインストールが驚くほど時間かかったから、不安になる...
大規模なプロジェクトとかになってくると変わってくるのかもしらんけど、何か、そこまで規模が大きくならないならDockerで良いような気がする…
ネットの情報だと、Dockerに比べてかなり速くなるって話が多かったので、期待値が上がり過ぎて、遅いと感じてしまっただけなのかもしれないですが...
バイアスがかかってしまっていたということにしておこう...
VS Code（Visual Studio Code）が、もうちょっと設定なんかについて分かりやすく改善されるとありがたいんですけどね...Microsoftさんだから致し方ないのかもしれませんが...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
