Eclipse環境でしか、Javaを動かしたことがないですが（Java講座ではコマンドプロンプトでも動かした）、本番環境にはEclipseなどのような統合開発環境を入れない方が良いとなると、どうするの？
ということで、ビルドツールが必要になってくるようです。IDE（統合開発環境）では独自のビルドツールがIDEに組み込まれているようです。
結論としては、ローカル環境のEclipseでwarファイルを作成し、本番環境のアプリケーションサーバー（ここではTomcatのある、/opt/tomcat/webapps）に配置すれば良いようです。
⇩ 本番環境にデプロイするということについては下記サイトへ
・Java製アプリを Eclipse から実行したことしかない新人に「ビルドツールとは？」を説明してみる…そして CI へ - Qiita
前回も載せさせてもらいましたが、今回も。
ビルドとは？
そもそも、ビルドツールって何なのさ？というか、Eclipseでも、「ビルドパスの構成」「自動ビルド」とか、ちまたにあふれてた「ビルド」って何なのさ？
ビルド (ソフトウェア)
ソフトウェアのビルド（英: build）は、ソースコードファイルを独立したソフトウェア生成物に変換するコンピュータ上で実行されるプロセス、またはその結果を指す。
ビルドにおいて最も重要なのはコンパイルプロセスであり、ソースコードファイルを実行ファイルに変換する。
単純なプログラムでは、単一のファイルをコンパイルするだけで済むが、複雑なソフトウェアではソースコードは多数のファイルで構成されており、異なった組み合わせ方をすることで異なったバージョンを生成できる。
コンピュータプログラムのビルドは、一般にビルドツールと呼ばれるプログラムを使い、他のプログラムを制御・統合して行う。
ビルドツールの例としては、make、ant、maven、SConsなどがある。
ビルドユーティリティは、各種ファイル群を正しい順序でコンパイルしリンクする必要がある。また、開発時には何度もビルドを繰り返すが、前回のビルドから何も変更されていないファイルはコンパイルする必要がない（ただし、ヘッダファイルなどの依存関係も考慮する必要がある）。
洗練されたビルドユーティリティは無駄な再コンパイルをしないようにして、ビルドに要する時間を短縮している。
Subversionなどのバージョン管理システムはビルドユーティリティの機能を内蔵している。
さらに複雑なプロセスになると、ビルド中に他のプログラムを使ってコードやデータを生成することもある。
う～ん、とりあえず、Java単独でなく、MySQLとかも使ってる複合的なプロジェクトは、「コンパイル」だけじゃまずいから、「ビルド」 しとけってことですかね？
ビルドの歴史
Wikipediaさんの情報に頼り切ってますが、
一般に、プログラムはソースファイルをコンパイルしリンクすることで、実行ファイルとなる。ソースファイルが1つしかないなら、それらの作業をコマンドラインから実行するのも簡単だが、ソースファイルが多数存在するプロジェクトでは、正しい順序とオプションで手作業するのは至難の業である。
この問題を解決する手段としてmakeのようなスクリプト言語が登場した。それにより、コンパイルやリンクを正しい順序で行うスクリプトを書くことができる。GNU Makeでは更にソースコードの依存関係を管理でき、変更された部分だけをコンパイルするインクリメンタルビルドが可能になった。
これがビルドの自動化の始まりである。その第一の目的はコンパイラやリンカの呼び出しを自動化することだった。
ビルドプロセスが複雑化するに従い、コンパイラ呼び出しの前後に様々な作業（バージョン管理システムからのチェックアウトや生成した実行ファイルのテスト環境への投入など）を追加するようになった。
「ビルド」の当初の目的は、「コンパイラ」や「リンカ」の呼び出しを自動化することだったようですね。
さらに、ビルドツールは進化し、スクリプト（Makefile）自体を生成するものが登場した。これらツールは、頻繁にビルドを行う継続的インテグレーションで特に便利である。
とどまること知らない、時の流れ～、じゃないですが、便利になったようです。
「分散ビルド」なるものも出てきてますが、ビルドツールでも「分散ビルド」ができるものは限られてくるみたいですね。
高度なビルドツールは分散ビルドや分散処理が可能である。「分散ビルド」とは、実際のコンパイルやリンクをそれぞれ別々のマシン上で行い、ビルドを高速化する手法である。
一方、分散処理とは例えば、テスト用スクリプトを複数のマシンに配置し、新たな実行ファイルのテストを分散環境で自動的に行うことなどを指す。
分散ビルドを行うには、ソースコードの依存関係を自動的に把握することが必須である。
一部のビルドツールは依存関係を自動的に発見でき（Ratinal ClearMake、Electric Cloud ElectricAcceleratorなど）、別のビルドツールではユーザーが定義した依存関係のみを扱う（Platform LSF lsmakeなど）。
ソースコードの依存関係を把握できるビルドツールは、コンパイルおよびリンクを並行モードで実行するよう設定できる。すなわち、コンパイラやリンカを複数コアのマシン上でマルチスレッドモードで実行することができる。
全てのビルドツールが分散ビルドを実施できるわけではない。
分散ビルドの例として Xoreax の IncrediBuildがある。
というわけで、世の中の流れ的には「ビルドツール」使っていこう、ということなんですかね？
Javaで利用できるビルドツール
Javaで利用できるビルドツールには、
など、様々なものがあるようです。
継続的インテグレーション
継続的インテグレーション、CI（英: continuous integration）とは、主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。
エクストリーム・プログラミング (XP) のプラクティスの一つで、狭義にはビルドやテスト、インスペクションなどを継続的に実行していくことを意味する。
特に、1990年代後半以降の開発においては、継続的インテグレーションをサポートするソフトウェアを使用する傾向が強まってきた。
「ビルド・テスト・デプロイ」などを自動化し、一日に何度も繰り返す手法のことみたいです。「エクストリーム・プログラミング」は、アジャイルソフトウェア開発の方法論の1つで、刻一刻と変化する顧客の要求に対応しつつ、変更コストが増大しないという前提で開発することらしいです。
「エクストリーム・プログラミング」による開発をしている中で、「継続的インテグレーション」は生まれたようです。
Javaで利用できる継続的インテグレーションツール
継続的インテグレーションを実装してくれるツールには、
- Jenkins（オープンソース）
- Bamboo
- エンタープライズ向け製品の大手なAtlassianが提供。オンプレミス利用可能。
- CircleCI
- 2013年頭頃公開、500 startupsから投資されてスタートしたCI。
- TravisCI
などがあるようですが、「Jenkins」の生みの親は、「川口耕介」さんという日本の方のようです。
継続的インテグレーションに必要なもの
継続的インテグレーションツール以外にも必要なものがあり、一般的なシステム構成では、
- 継続的インテグレーションサーバー
- Jenkinsなど
- ソースコード管理システム
- Git、Subvirsion、Mercurialなど
- ビルドツール
- Bazel、Gradle、Maven、Antなど
- テストツール
- テストカバレッジ取得ツール
- JaCoCo（Emmaの後継）、Emma、Coberturaなど
- インスペクションツール
- フィードバック機能
- レポート機能
の6つのツール + 2つの機能があると良いようです。
ローカル環境を本番環境にデプロイするには？
実際には、ローカル環境のEclipseでプロジェクトのwarファイルを作成し、本番環境のTomcat（自分の場合だと、/opt/tomcat/webappsフォルダ）に配置すれば良いみたいです。
で、ローカルにあるwarファイルを本番環境のTomcatにアップするのも、Eclipseに RSE（Remote Server Explorer）プラグインを導入すれば簡単みたい。
・warファイルを Tomcat上で動作させる - ScalaのようでJavaだけど少しScalaなJSON API - ワルブリックス株式会社
・Eclipseでwarファイルを作成し、Tomcatにデプロイする手順 | ITSakura
ローカル環境でプロジェクトをwarファイルに
ローカル環境でEclipseを立ち上げ、「プロジェクト・エクスプローラー」で本番環境にデプロイしたいプロジェクトを選択した状態で右クリックし、「エクスポート（X）」>「WAR ファイル」を選択。
「宛先（D）:」は適当に決めて、一応、「ターゲット・ランタイム（T）」を本番環境に近い「Apache Tomcat v9.0」にして、「完了（F）」を選択。
「宛先（D）:」で指定した先に、warファイルができます。
ローカル環境のEclipseに RSE（Remote Server Explorer）プラグインを導入...されてる？
本番環境へファイルをアップしたりするには、GUIツールでWindowsの場合、「ffftp」や「Win SCP」など でできるのですが（自分の体験だとPHPのフレームワークとか使ってないのはいけた）、EclipseにRSE（Remote Server Explorer）プラグインというものを導入することでもいけるみたいです。
・Eclipseからサーバー環境に接続してファイルを直接編集する方法！FTPツール使うより捗りますよ
「ヘルプ（H）」>「新規ソフトウェアのインストール...」を選択。
「すべての使用可能なサイト」を選択して、むちゃくちゃ待たせられるんですが、
保留中...の時間が異常に長いでござる。にもかかわらず、
表示結果のどこにも「Remote System Explorer」なんぞ、見つからんとなり、
近いのは見つかるも、何か違う。
試しに「ヘルプ（H）」>「Eclipse マーケットプレイス（M）...」を選択。
「検索（I）:」で「Remote System Exploere」で検索すると、「インストール済み」となっています！インストールした覚えないよ！
嫌な予感ですが、Eclipseにデフォルトでインストールされてるってことですかね、そんなん知らんし！
「ウィンドウ」>「パースペクティブを開く」>「その他」
存在しているという！
⇩ こちらの方が記載してくれてました。見つけるのが遅れてハマってしまった
・Eclipse でリモート接続をしてみる | DualBalance
「リモート・システム」の「ローカル」を選択した状態で右クリックし、「新規（A）」>「接続（A）...」を選択。
「Linux」を選択し、「次へ（N）>」をクリック。
「ホスト名：」にGCP（Google Cloud Platform）のCompute Engineで作成したVMインスタンスの「外部IP」を指定。「接続名：」などは適当で。「次へ（N）>」をクリック。
「ssh.files」を選択し、「次へ（N）>」をクリック。
「processes.shell.linux」を選択し、「次へ（N）>」をクリック。
「sshshells」を選択し、「完了（F）」をクリック。
Remote Server Explorer接続設定のためにsshキーの作成
これまで、gcloudというGoogleが用意してくれていたコマンドでssh接続していたわけですが、外部アプリ（Tera Termなど）でssh接続するには、それ用のsshキーを作る必要があります。
・Linux インスタンスへの接続 | Compute Engine ドキュメント
というわけで、Windowsの場合は、https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html にアクセスします。
下の方にスクロールすると、「Alternative binary files」という項目の中に、「puttygem.exe」というリンクがあるので、お使いのPCに合わせ他方を選んでクリックします。（だいたい64bitになるかと）
ダウンロードされたexeファイルをダブルクリックすると、「PuTTY Key Generator」が起動するので、「Generate」をクリック。
「Key Comment」のところに、GCPのVMインスタンスでgcloudでssh接続していたときに表示されていたユーザー名（「ユーザー名@VMインスタンス名」のところのユーザー名）を入力します。「Key passphrase」はパスワードみたいな感じだと思われますが、適当に入力しておきます。そうしたら、「Save private Key」をクリックして「秘密鍵」を生成します。
ファイル名は適当に、「ファイルの種類（T）:」は、拡張子が「.ppk」にしておきます。保存場所は、「C:¥Users¥ユーザー名¥.ssh」フォルダに保存するのが一般的みたいです。「.ssh」フォルダがない場合は作成しときましょう。
続いて、「Save public key」をクリックで「公開鍵」を保存します。
といっても、「公開鍵」は、 GCP側に登録することになるので、とりあえず、テキストで保存しておく感じですかね。
そしたら、GCPのダッシュボードに戻り、「メタデータ」を選択します。
「SSH 認証鍵」を選択します。
「編集」を選択します。
「+ 項目を追加」をクリック。 新しいテキストエリア（「認証鍵全体を入力」）が表示されるので、
「Putty Key Generator」の「Public key for pasting in to OpenSSH authorized_keys file:」という欄の文字列をすべて選択コピーし、
GCPの、「認証鍵全体を入力」というところに張り付けます。「保存」を選択。
EclipseのRemote Server Explorerで接続...できない
Eclipseのリモート接続を試してみる。
「ユーザーID:（I）」にGCPのVMインスタンスのユーザー名を指定し、「OK」。
うん、接続できない。
・EGit（EclipseのGit）のSSH設定 - ひしだまの変更履歴
⇧ なんか、Java 8に対応できてないらしい...衝撃。
putty.exeで接続できるか試してみます。
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html にアクセスします。「putty.exe」のリンクを選択。（64bitで。）
「Host Name（or IP address）」には、VMインスタンスの「外部IP」だけでいけました。（Google Cloud Platformの公式のチュートリアルだとユーザー名を前に付けるってなってるけど。）
「Connection」>「SSH」>「Auth」 で「Private Key file for authentication」で「秘密鍵」を選択します。
さっき、「Putty Key Generator」で作成したやつを指定して、「Open」。
初回のみ警告が出ますが、「はい（Y）」を選択します。
「login as:」と聞かれるので、「Putty Key Generator」の「Key comment」で入力したもの（GCPのVMインスタンスの「ユーザー名」）を入力し、Enter。
その後、「Passphrase for key」と聞かれたら、「Putty Key Generator」の「Key passphrase」を入力し、Enter。すると、GCPのVMインスタンス（仮想マシン）にログインできます。
接続できたけど、CUIなんですよね。
ちょっと、想像以上にハマってしまったので、次回に持ち越しで。
次回は、Win SCPでGCPのVMインスタンスと接続を試みます。もう、GUI接続の希望の星は、それ以外残されてなさそうです。
warファイルはできたんで、あとは本番環境にアップするだけと信じたいです。
それにしても、散々苦労して見つけたEclipseのRemote Server Explorerが使えないとは、超絶ショックですね。便利さを体験したかったんですが。
今回はこのへんで。
