<このシリーズの、前の記事 | このシリーズの目次 | このシリーズの、次の記事>
我々のプロジェクトビルドシステムの使用法が説明される
話題: Gradle
話題: Ant
話題: Javaプログラミング言語
話題: UNO (Universal Network Objects)
話題: LibreOffice
話題: Apache OpenOffice
我々は、我々のいずれかのシリーズの中でzipファイルにアーカイブされたサンプルプログラムに言及する時、ある同じプロジェクトビルドシステムを使用している。プロジェクトをビルドする方法を毎回記述するのは面倒なので、ここ一箇所にそれを記述しよう。
オーケー。
我々はGradleかAntを使う(両方は必要ない)ので、その少なくとも1つとJDKをインストールしておかなければならない。これらのインストール方法は、Linux用はここ、Windows用はここに、既に記述した。
ふーむ、他の製品についての情報も含んでいるが、不要な部分は無視すればよい。
UNO拡張機能をビルドするのでなければ、LibreOffice(またはApache OpenOffice)、LibreOffice SDK(またはApache OpenOffice SDK)、wmctrlは必要ない。
各製品は好きなようにインストールして問題ないが、製品のバージョンは以下より上であると想定されている。
- JDK 1.8.0
- Ant 1.9.6
- Gradle 3.1
これより下のバージョンでは絶対うまくいかないと言っているわけではないだろう?
上のバージョンは我々が使ってきたバージョンだというだけだ。若干下のバージョンでうまくいかないとする特別の理由を私は知らない、JDKを除いては。JDKについては、下のバージョンではうまくいかないだろう。というのは、例えば、我々はラムダ表現を使っているから。
zipファイルにアーカイブされたサンプルプログラムに我々が言及したとき、そのzipファイルは、ディレクトリ構造を維持して、あるディレクトリに展開しなければならない。
この、展開のルートディレクトリを、「開発ベースディレクトリ」と呼ぼう。
開発ベースディレクトリの下のディレクトリ群は、プロジェクトディレクトリ群であり、開発ベースディレクトリの下の'commonBuild*.gradle'、'commonBuild*.xml'、'commonBuild.properties'は、共通(「他の、プロジェクト専用ビルドスクリプトまたはビルドファイルによって使われている」という意味)ビルドスクリプトまたはビルドファイルだ。全てのプロジェクトをビルドするには . . .
その前に、共通ビルドスクリプトまたはビルドファイル1つのいくつかのプロパティを変更しなければならないように思ったが。
ああ、忘れていた。UNO拡張機能プロジェクトをビルドする場合は、Antの'commonBuild.properties'またはGradleの'commonBuild01.gradle'の'LIBREOFFICE_DIRECTORY_NAME'と'LIBREOFFICE_SDK_DIRECTORY_NAME'は、もし、それらが自環境と合っていなければ、変更しなければならない。
それらをどのように変更すればよいのか?
'LIBREOFFICE_DIRECTORY_NAME'は、LibreOfficeがインストールされたディレクトリ、'LIBREOFFICE_SDK_DIRECTORY_NAME'は、LibreOffice SDKがインストールされたディレクトリだ。Windowsでは、これらは、常に変更しなければならないだろう。その際、ディレクトリの区切り文字には、'\'ではなく'/'を使う(例えば、'D:/LibreOffice')。
ふーむ . . .
LibreOfficeのバージョンが我々が予期しているものより下の場合、変更しなければならない他のプロパティーもあるかもしれない。
最低バージョンとして我々が予期しているものはなんだ?
'5.1.4'だ。
ふーむ . . .
プロパティが正しく設定されたら、開発ベースディレクトリをカレントディレクトリにして、'gradle'または'ant'を実行すると、すべてのプロジェクトがビルドされる。
個別のプロジェクトをビルドしたい場合は、そのプロジェクトディレクトリをカレントディレクトリにして、'gradle'または'ant'を実行すればよい。
ターゲットである生成物はどこにあるのか?
各プロジェクトディレクトリの'target'ディレクトリにあるはずだ。
プロジェクトがUNO拡張機能プロジェクトである場合、UNO拡張機能は、LibreOfficeに登録される。その前に、LibreOfficeのプログラムインスタンス(もしあれば)を落とそうと試みられるだろう。
まだ保存していない文書を無慈悲に閉じて突然落とすわけではないのだろう?
そうした文書を保存するように丁重に尋ねられる。
共通ビルドスクリプト群と共通ビルドファイル群は、このサイトで言及される全てのzipファイルに含まれている。1つのディレクトリに2つのzipファイルを展開した場合、古いものは、新しいもので上書きすべきなのか?
新しいもの(ファイル変更日を見て欲しい)で古いものを上書きすべきだ。新しいものはどのプロジェクトもうまく扱えるはずだ(バグがなければだが)。
複数のzipファイルに含まれているユーティリティプロジェクトはどうだ?
うーん、これらは、実験中のプロジェクトだから、我々はこれらを頻繁に変更し、互換性を常に維持しているわけではない。もし、新しいユーティリティプロジェクトがより古いプロジェクトと合わなければ、zipファイルは別のディレクトリに展開しなければならないだろう。または、我々は、このサイトのzipファイルを、新しいユーティリティプロジェクトに対応したアップデートされたzipファイルで置き換えるので、アップデートされたzipファイルを使うこともできる。
すると、あるzipファイル内のプロジェクトには、そのzipファイルに言及している記事に関係ない多くのファイルが含まれる可能性があるということになる。
実際、そういうことになる。まあ、分かるだろうが、各zipファイルから無関係なファイルを除くのは大変すぎるから . . .
それでは、もし、ある記事で言及されたzipファイルに、無関係なファイル群が含まれていたら、それは、ほかの記事のためのものなわけだ。
既存のプロジェクトディレクトリは、zipファイルにそれらのプロジェクトが含まれている場合、そのzipファイルを展開する前に削除する必要はないのか?
原則としては、そうしなければならない、というのも、zipファイルのそうしたプロジェクトから一部のファイルが削除されている可能性があるから。ただし、多くの場合、それらを削除しなくても害はなにもないだろう。
あるプロジェクトにJavaのメインクラス(mainメソッドを持つクラス)が含まれている場合、そのプログラムを、プロジェクトディレクトリをカレントディレクトリにして、以下のようにして実行できる
Gradleの場合:
gradle run -PMAIN_CLASS_NAME="<the main class name>" -PCOMMAND_LINE_ARGUMENTS="<the command line arguments>"
Antの場合:
ant run -DMAIN_CLASS_NAME="<the main class name>" -DCOMMAND_LINE_ARGUMENTS="<the command line arguments>"