GraghQLのexampleを試す際に、Git Hubに上がってるプロジェクトがGradleを利用していたということで、Gradleの知識が必要になってきたので、今回はGradleのインストールにトライ。
Eclipseのアップデートに絶賛ドハマリ中でしたが、解決できました。
ts0818.hatenablog.com
そんなこんなで、今回は、バックエンド側のビルドツールであるGradleにチャレンジ。
Gradleとは？
Wikipediaさ～ん！
GradleはApache AntやApache Mavenのコンセプトに基づくオープンソースビルド自動化システムであり、プロジェクト設定の宣言にはApache Mavenが利用するXML形式ではなくGroovyベースのドメイン固有言語 (DSL) を採用している。
Gradleはタスクの起動順序の決定に有向非巡回グラフ（英: Directed Acyclic Graph、DAG）を利用する。
⇧ Apache Ant、Apache Maven なんかと同じくビルドツールというものらしい。ただ、Gradleは、xml形式ではなく、スクリプトで 記述するようです。
Googleの作ったビルドツールであるBazelなんかに近い感じですかね？
Androidの標準のビルドツールとして採用されてるのが、Gradleなんだとか。
ずっと「グラドル」って、グラビアアイドルの略みたいな名前だな～と思ってたけど、「グレイドル」って読みが正解らしい、たぶん...。
ちなみに、フロントエンドでは、ビルドツールというと、Browserify、gulp、Webpackなんかがありますが、最近は、Parcel っていうのが勢いがあるみたいですね。
Gradleのインストール
⇧ 上記サイト様によりますと、
Gradle runs on all major operating systems and requires only a Java JDK or JRE version 7 or higher to be installed. To check, run java -version:
と、Javaがインストールされてないと駄目らしい。
大丈夫そうですね。
そしたらば、Windowsで利用できるパッケージ管理ツールのChocolatey でインストールできるらしい。
コマンドプロンプトを管理者権限で起動し、
choco install gradle
環境変数に、gradleのパスを追加。
refreshenv
バージョンが表示されればOKっぽいです。
Gradle Wrapperとは？
https://docs.gradle.org/4.10.2/userguide/gradle_wrapper.html によると、
The recommended way to execute any Gradle build is with the help of the Gradle Wrapper (in short just “Wrapper”). The Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary. As a result, developers can get up and running with a Gradle project quickly without having to follow manual installation processes saving your company time and money.
と、Gradleで作成したプロジェクトを自動でインストールしてくれるらしい。
Gradle Wrapperの仕組みイメージ図
Generating the Wrapper files requires an installed version of the Gradle runtime on your machine as described in Installation. Thankfully, generating the initial Wrapper files is a one-time process.
⇧ 事前に、Gradle をインストールしておく必要があるようです。
で、Wrapper properties fileを作成するには、
gradle wrapper
のコマンドを実行するらしい。Gradle distribution がServerに登録されるらしい、Serverが何のことを言ってるのか？ですが。
Every vanilla Gradle build comes with a built-in task called wrapper. You’ll be able to find the task listed under the group "Build Setup tasks" when listing the tasks. Executing the wrapper task generates the necessary Wrapper files in the project directory.
⇧ 説明が漠然としすぎでしょう...
⇧ 上記サイト様が、非常に分かりやすいです。
要するに、大規模プロジェクトがあった場合に、初めに管理者的な役割の人のPCにだけGradleをインストールして、「gradle wrapper」コマンドを実行することで、作成されるスクリプトファイルができると。
| OS | スクリプトファイル |
|---|---|
| LinuxやOS X(Mac)用 | gradlew |
| Windows用 | gradle.bat |
⇧ LinuxやOS X(Mac)の場合は、「gradlew」というシェルスクリプトのファイル、Windowsの場合は「gradle.bat」というバッチスクリプトファイルを使っていくみたいですかね。
他の開発者の人たちは、このスクリプトファイルを叩けばまったく同じプロジェクトの環境を構築できると。つまり、プロジェクトのバージョン管理っぽいことができる？ってことですかね。
開発者同士で環境が変わるのは宜しくないと思われるので、こういう仕組みは嬉しいですね。
IDE（統合開発環境）についても、プロジェクトで統一 できたら良いと思うんですけどね。
そして、Gradle Wrapperのイメージ図に出てきたServerは、リポジトリのことらしいのではないかと。Gradle Wrapperのイメージ図で、Serverから「Download distibution」ってなってるしね。
Wrapperタスクを設定する際は、使いたいGradleのバージョンを指定することができます。その場合、作成されるgradlewコマンドはGradleリポジトリから適切なディストリビューションを選んでダウンロードします。
でも、
Gradleは、どうやって外部依存関係を見つけるのでしょうか？ Gradleは、それらをリポジトリから探します。リポジトリの実体は、ただのファイルの集合です。それらのファイルは、グループ、名前、そしてバージョンによって分類されています。Gradleは、MavenやIvyなど、様々なリポジトリ形式に対応できます。また、ローカルファイルシステムやHTTPなど、リポジトリにアクセスするための手段についても様々なものを使うことができます。
デフォルトでは、Gradleはリポジトリを一切定義していません。外部依存関係を使うには、少なくとも一つのリポジトリを定義する必要があります。 選択肢の一つは、Mavenのセントラルリポジトリを使うことです。
⇧ デフォルトでは、Gradleリポジトリは一切定義されてないって...
依存関係でなく、ただのGradleのディストリビューションをダウンロードする分には、リポジトリは定義されてなくても問題ないんですかね？
なんか、「C:¥Users¥ユーザ名¥.gradle」ってディレクトリが作成されてるんですが、そこが、「Gradle User Home」ってことになるんですかね？
いや～、Gradleもなかなかに情報がカオスですな。
プロジェクトを作成し、Gradle Wrapperしてみる
前回、Eclipseの更新をしてみたんで、EclipseでJava的なプロジェクトを作成して、そのプロジェクトでGradle Wrapperしてみたいと思います。
Eclipseを起動。
うん...なんか、Eclipseをインストールしてたフォルダ名を変えたら、ワークスペースの名前が一致しなくなって、「パッケージエクスプローラー」に以前作ってたプロジェクトが表示されないと。
っていうか、以前の名前「Eclipse4.6」で勝手にワークスペースが作られると...。
一旦、Eclipseを終了して、「eclipse.exe-clean.cmd」で起動し直してみます。
なるほど...Eclipseインストールしてるディレクトリ名を変えちゃうと、既に作成してたワークスペースのパスは自分で変えないとマズイらしい...これ、ワークスペースが100個とかあったら地獄ですな。「参照(B)...」で、
「C:¥Eclipse_2018-09¥pleiades¥workspace05」を選択して、「フォルダーの選択」をクリック。
「起動(L)」で。
⇧ 以前作ってたワークスペース読み込めたけど、外部jarとして追加したライブラリがインポートされてない...標準のJavaAPIでないものは、自分でビルド・パスに追加し直さないといけないみたいね...
まぁ、今回は、新規プロジェクトを作成するということで、外部Jarの問題の調査は後日、時間があればということで。
「ファイル(F)」>「新規(N)」>「Gradle プロジェクト」。
「プロジェクト名」を適当に付けて、「次へ(N)>」。
特に何もせず、「次へ(N)>」。
ファイアーウォールが出てきたら、「アクセスを許可する(A)」。
「完了(F)」。
Eclipseの場合は、Gradleプロジェクトを作成することで、Gradle Wrapperしたことになるらしい。「gradlew」、「gradle.bat」なんかのバッチファイル的なものができてるみたいですしね。たぶん、このプロジェクトをzipなんかにして、他の開発者の人は、ワークスペースにインポートして、Windowsの場合だったら、「gradle.bat」を実行すれば同じGradleプロジェクトの環境構築ができると。
gitやSVNなどのバージョン管理ツールを使ってる場合は、gitだったらクローン、SVNだったらチェックアウトをし、「gradle.bat」を実行すればOKってことですかね。
というわけで、進行中の大規模プロジェクトなんかに参画することになった場合で、Gradleでプロジェクトができているような場合は、既に作成されてるプロジェクトを自分のPCに落としてきて、Windowsの場合だったら、「gradle.bat」を実行すれば良いのだと思われます。
まぁ、何ていうか、Gradleインストールする必要なかったっってことですかね...
そして、Gradle Wrapperのアーキテクト図がモヤっとしすぎてモヤモヤ感が半端ないですね。
今回はこのへんで。
2018年10月27日（土）追記： ↓ ここから
⇧ 上記サイト様によりますと、外部ライブラリの依存関係が解決できていないらしい。どちらにしろ、プロジェクトを複数一括でまとめて解決はできなさそう。
そして、パースペクティブが、「Java」の修正の仕方では無かったようです...
私の場合は、Eclipseのインストールディレクトリの名前を、「Eclipse4.6」から「Eclipse2018-09」に途中で変えたのがまずかったようです。
ワークスペースで、ビックリマークのついてるプロジェクトの「.classpath」を開いてみると、
⇧ 見事に、外部ライブラリの参照先である「path」が、変更前のディレクトリのままになってしまっている...。
Eclipseのほうでも確認。プロジェクトを選択した状態で右クリックし、「ビルド・パス(B)」>「ビルド・パスの構成(C)...」を選択。
こちらも見事に、外部ライブラリの参照先である「path」が、変更前のディレクトリのままになってしまっている。
とりあえず、「.classpath」ファイルの「path」を修正し、
Eclipseの「パッケージ・エクスプローラー」上のプロジェクトを選択した状態で、「F5」でリフレッシュすると、ビルド・パスの問題が解決できました。
Eclipseから、修正する場合は、「ビルド・パス(B)」>「ビルド・パスの構成(C)...」の「ライブラリタブ(L)」でエラーになってるライブラリを選択し、「除去(R)」後、改めて「外部JARの追加(X)」で、「適応(A)」。
で、Eclipseの「パッケージ・エクスプローラー」上のプロジェクトを選択した状態で、「F5」でリフレッシュで解決できるかと。
⇧ 上記サイト様を参考にさせていただきました。
プロジェクトを選択した状態で右クリックし、「ビルド・パス(B)」>「ビルド・パスの構成(C)...」を選択。
「ライブラリ(L)」タブで、「JREシステム・ライブラリー[Java8](アンバインド済み)」を選択した状態で、「編集(E)...」をクリック。
JREが選択されていないので、
「ワークスペースのデフォルトJRE(D)(jre)」のラジオボタンを選択し、「完了(F)」。
「適用(A)」後、
「順序およびエクスポート(O)」タブに切り替えて、
「すべて選択(C)」し、「適応(A)」で「Apply and Close」で。
で、プロジェクトのリフレッシュでエラーが...消えない
⇧ 上記サイト様によりますと、「インポートされた javax.servlet は見つかりません」は、Apache TomcatのライブラリをEclipseのプロジェクトが認識できてないと。
Apache Tomcatのライブラリの「servlet-api.jar」を追加。
「適応(A)」で。
エラーが消えました。
久々で、Servletのことすっかり忘れてますね...。
2018年10月27日（土）追記： ↑ ここまで
