WindowsにGradleをインストール。Gradleをインストールしなくてもgradle.batとかは実行できるらしい

GraghQLのexampleを試す際に、Git Hubに上がってるプロジェクトがGradleを利用していたということで、Gradleの知識が必要になってきたので、今回はGradleのインストールにトライ。

Eclipseのアップデートに絶賛ドハマリ中でしたが、解決できました。
ts0818.hatenablog.com

 

そんなこんなで、今回は、バックエンド側のビルドツールであるGradleにチャレンジ。 

 

 

Gradleとは?

Wikipediaさ~ん!

GradleApache AntApache Mavenのコンセプトに基づくオープンソースビルド自動化システムであり、プロジェクト設定の宣言にはApache Mavenが利用するXML形式ではなくGroovyベースのドメイン固有言語 (DSL) を採用している

Gradleはタスクの起動順序の決定に有向非巡回グラフDirected Acyclic Graph、DAG)を利用する。

Gradle - Wikipedia

⇧  Apache Ant、Apache Maven なんかと同じくビルドツールというものらしい。ただ、Gradleは、xml形式ではなく、スクリプトで 記述するようです。

Googleの作ったビルドツールであるBazelなんかに近い感じですかね?

Androidの標準のビルドツールとして採用されてるのが、Gradleなんだとか。

ずっと「グラドル」って、グラビアアイドルの略みたいな名前だな~と思ってたけど、「グレイドル」って読みが正解らしい、たぶん...。

yomikata.org

 

ちなみに、フロントエンドでは、ビルドツールというと、Browserify、gulp、Webpackなんかがありますが、最近は、Parcel っていうのが勢いがあるみたいですね。

 

 

Gradleのインストール

gradle.org

⇧  上記サイト様によりますと、

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:

https://gradle.org/install/

と、Javaがインストールされてないと駄目らしい。

f:id:ts0818:20181014204627p:plain

大丈夫そうですね。

そしたらば、Windowsで利用できるパッケージ管理ツールのChocolatey でインストールできるらしい。

コマンドプロンプトを管理者権限で起動し、

choco install gradle

f:id:ts0818:20181014205333p:plain

f:id:ts0818:20181014205426p:plain

環境変数に、gradleのパスを追加。

refreshenv

f:id:ts0818:20181014205608p:plain

バージョンが表示されればOKっぽいです。 

f:id:ts0818:20181014205929p:plain

 

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.

The Gradle Wrapper

と、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.

The Gradle Wrapper

⇧  事前に、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.

The Gradle Wrapper

⇧   説明が漠然としすぎでしょう...

 

qiita.com

⇧  上記サイト様が、非常に分かりやすいです。

要するに、大規模プロジェクトがあった場合に、初めに管理者的な役割の人のPCにだけGradleをインストールして、「gradle wrapper」コマンドを実行することで、作成されるスクリプトファイルができると。

OS スクリプトファイル
LinuxOS X(Mac)用 gradlew
Windows gradle.bat

⇧  LinuxOS X(Mac)の場合は、「gradlew」というシェルスクリプトのファイル、Windowsの場合は「gradle.bat」というバッチスクリプトファイルを使っていくみたいですかね。

 

他の開発者の人たちは、このスクリプトファイルを叩けばまったく同じプロジェクトの環境を構築できると。つまり、プロジェクトのバージョン管理っぽいことができる?ってことですかね。

開発者同士で環境が変わるのは宜しくないと思われるので、こういう仕組みは嬉しいですね。

IDE統合開発環境)についても、プロジェクトで統一 できたら良いと思うんですけどね。

 

そして、Gradle Wrapperのイメージ図に出てきたServerは、リポジトリのことらしいのではないかと。Gradle Wrapperのイメージ図で、Serverから「Download distibution」ってなってるしね。

Wrapperタスクを設定する際は、使いたいGradleのバージョンを指定することができます。その場合、作成されるgradlewコマンドはGradleリポジトリから適切なディストリビューションを選んでダウンロードします。

第62章 Gradleラッパー

でも、

Gradleは、どうやって外部依存関係を見つけるのでしょうか? Gradleは、それらをリポジトリから探します。リポジトリの実体は、ただのファイルの集合です。それらのファイルは、グループ名前、そしてバージョンによって分類されています。Gradleは、MavenやIvyなど、様々なリポジトリ形式に対応できます。また、ローカルファイルシステムやHTTPなど、リポジトリにアクセスするための手段についても様々なものを使うことができます。

デフォルトでは、Gradleはリポジトリを一切定義していません。外部依存関係を使うには、少なくとも一つのリポジトリを定義する必要があります。 選択肢の一つは、Mavenのセントラルリポジトリを使うことです。

第8章 依存関係管理の基本

⇧  デフォルトでは、Gradleリポジトリは一切定義されてないって...

依存関係でなく、ただのGradleのディストリビューションをダウンロードする分には、リポジトリは定義されてなくても問題ないんですかね?

 

なんか、「C:¥Users¥ユーザ名¥.gradle」ってディレクトリが作成されてるんですが、そこが、「Gradle User Home」ってことになるんですかね?

f:id:ts0818:20181020201939p:plain

いや~、Gradleもなかなかに情報がカオスですな。

 

プロジェクトを作成し、Gradle Wrapperしてみる

前回、Eclipseの更新をしてみたんで、EclipseJava的なプロジェクトを作成して、そのプロジェクトでGradle Wrapperしてみたいと思います。

Eclipseを起動。

f:id:ts0818:20181020172554p:plain

f:id:ts0818:20181020173956p:plain

うん...なんか、Eclipseをインストールしてたフォルダ名を変えたら、ワークスペースの名前が一致しなくなって、「パッケージエクスプローラー」に以前作ってたプロジェクトが表示されないと。

f:id:ts0818:20181020174748p:plain

っていうか、以前の名前「Eclipse4.6」で勝手にワークスペースが作られると...。

一旦、Eclipseを終了して、「eclipse.exe-clean.cmd」で起動し直してみます。

f:id:ts0818:20181020175743p:plain

なるほど...Eclipseインストールしてるディレクトリ名を変えちゃうと、既に作成してたワークスペースのパスは自分で変えないとマズイらしい...これ、ワークスペースが100個とかあったら地獄ですな。「参照(B)...」で、

f:id:ts0818:20181020180255p:plain

「C:¥Eclipse_2018-09¥pleiades¥workspace05」を選択して、「フォルダーの選択」をクリック。

f:id:ts0818:20181020180600p:plain

「起動(L)」で。

f:id:ts0818:20181020180921p:plain

f:id:ts0818:20181020181231p:plain

⇧  以前作ってたワークスペース読み込めたけど、外部jarとして追加したライブラリがインポートされてない...標準のJavaAPIでないものは、自分でビルド・パスに追加し直さないといけないみたいね...

まぁ、今回は、新規プロジェクトを作成するということで、外部Jarの問題の調査は後日、時間があればということで。

 

「ファイル(F)」>「新規(N)」>「Gradle プロジェクト」。

f:id:ts0818:20181020192916p:plain

「プロジェクト名」を適当に付けて、「次へ(N)>」。

f:id:ts0818:20181020193116p:plain

特に何もせず、「次へ(N)>」。

f:id:ts0818:20181020193151p:plain

ファイアーウォールが出てきたら、「アクセスを許可する(A)」。

f:id:ts0818:20181020193330p:plain

「完了(F)」。

f:id:ts0818:20181020193400p:plain

Eclipseの場合は、Gradleプロジェクトを作成することで、Gradle Wrapperしたことになるらしい。「gradlew」、「gradle.bat」なんかのバッチファイル的なものができてるみたいですしね。たぶん、このプロジェクトをzipなんかにして、他の開発者の人は、ワークスペースにインポートして、Windowsの場合だったら、「gradle.bat」を実行すれば同じGradleプロジェクトの環境構築ができると。

gitやSVNなどのバージョン管理ツールを使ってる場合は、gitだったらクローン、SVNだったらチェックアウトをし、「gradle.bat」を実行すればOKってことですかね。

f:id:ts0818:20181020195943p:plain

というわけで、進行中の大規模プロジェクトなんかに参画することになった場合で、Gradleでプロジェクトができているような場合は、既に作成されてるプロジェクトを自分のPCに落としてきて、Windowsの場合だったら、「gradle.bat」を実行すれば良いのだと思われます。

まぁ、何ていうか、Gradleインストールする必要なかったっってことですかね...

そして、Gradle Wrapperのアーキテクト図がモヤっとしすぎてモヤモヤ感が半端ないですね。

 

今回はこのへんで。

2018年10月27日(土)追記:  ↓  ここから

tech-son.hatenablog.jp

⇧  上記サイト様によりますと、外部ライブラリの依存関係が解決できていないらしい。どちらにしろ、プロジェクトを複数一括でまとめて解決はできなさそう。

そして、パースペクティブが、「Java」の修正の仕方では無かったようです...

私の場合は、Eclipseのインストールディレクトリの名前を、「Eclipse4.6」から「Eclipse2018-09」に途中で変えたのがまずかったようです。

f:id:ts0818:20181027125016p:plain

ワークスペースで、ビックリマークのついてるプロジェクトの「.classpath」を開いてみると、

f:id:ts0818:20181027125215p:plain

⇧  見事に、外部ライブラリの参照先である「path」が、変更前のディレクトリのままになってしまっている...。

Eclipseのほうでも確認。プロジェクトを選択した状態で右クリックし、「ビルド・パス(B)」>「ビルド・パスの構成(C)...」を選択。

f:id:ts0818:20181027125446p:plain

こちらも見事に、外部ライブラリの参照先である「path」が、変更前のディレクトリのままになってしまっている。

f:id:ts0818:20181027125924p:plain

とりあえず、「.classpath」ファイルの「path」を修正し、

f:id:ts0818:20181027130139p:plain

Eclipseの「パッケージ・エクスプローラー」上のプロジェクトを選択した状態で、「F5」でリフレッシュすると、ビルド・パスの問題が解決できました。

f:id:ts0818:20181027130251p:plain

Eclipseから、修正する場合は、「ビルド・パス(B)」>「ビルド・パスの構成(C)...」の「ライブラリタブ(L)」でエラーになってるライブラリを選択し、「除去(R)」後、改めて「外部JARの追加(X)」で、「適応(A)」。

で、Eclipseの「パッケージ・エクスプローラー」上のプロジェクトを選択した状態で、「F5」でリフレッシュで解決できるかと。

 

パースペクティブが「Java EE」の場合は、

www.kurabeat.com

⇧  上記サイト様を参考にさせていただきました。

プロジェクトを選択した状態で右クリックし、「ビルド・パス(B)」>「ビルド・パスの構成(C)...」を選択。

f:id:ts0818:20181027132731p:plain

「ライブラリ(L)」タブで、「JREシステム・ライブラリー[Java8](アンバインド済み)」を選択した状態で、「編集(E)...」をクリック。

f:id:ts0818:20181027132918p:plain

JREが選択されていないので、

f:id:ts0818:20181027133146p:plain

ワークスペースのデフォルトJRE(D)(jre)」のラジオボタンを選択し、「完了(F)」。

f:id:ts0818:20181027133302p:plain

「適用(A)」後、

f:id:ts0818:20181027133428p:plain

「順序およびエクスポート(O)」タブに切り替えて、

f:id:ts0818:20181027133710p:plain

 「すべて選択(C)」し、「適応(A)」で「Apply and Close」で。

f:id:ts0818:20181027133832p:plain

で、プロジェクトのリフレッシュでエラーが...消えない

f:id:ts0818:20181027134632p:plain

 

starscream.hatenablog.com

⇧  上記サイト様によりますと、「インポートされた javax.servlet は見つかりません」は、Apache TomcatのライブラリをEclipseのプロジェクトが認識できてないと。

f:id:ts0818:20181027135303p:plain

Apache Tomcatのライブラリの「servlet-api.jar」を追加。

f:id:ts0818:20181027135512p:plain

「適応(A)」で。

f:id:ts0818:20181027135642p:plain

エラーが消えました。

f:id:ts0818:20181027135710p:plain

久々で、Servletのことすっかり忘れてますね...。 

 

2018年10月27日(土)追記:  ↑  ここまで