<The previous article in this series | The table of contents of this series | The next article in this series>
The Usage of Our Projects Build System Is Explained
About: Gradle
About: Ant
About: Java Programming Language
About: UNO (Universal Network Objects)
About: LibreOffice
About: Apache OpenOffice
The Purpose of This Article
When we cite sample programs archived in zip files in any of our series, we use the same projects build system. As it is troublesome to describe how to build projects each time, we will describe it at one place here.
OK.
The Build Environment Has to Have Been Built
As we use Gradle or Ant (not both of them are necessary), we have to have installed at least one of them and JDK. We have described how to install them here for Linux and here for Windows.
Well, they include also information about other products, but we can ignore irrelevant parts.
If we aren't building UNO extensions, LibreOffice (or Apache OpenOffice), LibreOffice SDK (or Apache OpenOffice SDK), and wmctrl are irrelevant.
We can install the products in any ways we want, but the versions of the products are expected to be higher than these.
- JDK 1.8.0
- Ant 1.9.6
- Gradle 3.1
You aren't saying that lower versions will never do, are you?
The versions above are just versions we have used; I don't know any particular reason why some lower versions won't do, except JDK. As for JDK, lower versions won't do because we use, say, lambda expressions.
How to Build Projects
As we cite sample programs archived in zip files, we have to expand the zip file with the directories structure preserved, in a directory.
We will call the root directory of the expansion 'the development base directory'.
The directories under the development base directory are project directories, and 'commonBuild*.gradle', 'commonBuild*.xml', and 'commonBuild.properties' under the development base directory are common (meaning 'used by other project-specific build scripts or build files') build scripts or build files. To build all the projects . . .
Before that, I thought, we have to modify some properties in a common build script or a common build file.
Ah, I forgot. When we intend to build UNO extension projects, properties, 'LIBREOFFICE_DIRECTORY_NAME' and 'LIBREOFFICE_SDK_DIRECTORY_NAME', in 'commonBuild.properties' for Ant or in 'commonBuild01.gradle' for Gradle have to be modified if they aren't correct for our environment.
How should we modify them?
'LIBREOFFICE_DIRECTORY_NAME' is the name of the directory where LibreOffice has been installed; 'LIBREOFFICE_SDK_DIRECTORY_NAME' is the name of the directory where LibreOffice SDK has been installed. On Windows, they will always have to be modified, and the directory separator to be used is '/', not '\', for example 'D:/LibreOffice'.
Hmm . . .
If the version of LibreOffice is lower that the one we expect, there might be other properties that have to be modified.
What is the version we expect as the lowest version?
'5.1.4'.
Hmm . . .
After the properties are correctly set, executing 'gradle' or 'ant' with the development base directory as the current directory will build all the projects.
When we want to build an individual project, we can execute 'gradle' or 'ant' with the project directory as the current directory
Where can we find target artifacts?
They should exist in the 'target' directory of each project directory.
When the project is a UNO extension project, the UNO extension will be registered into LibreOffice. Before that, the LibreOffice program instance (if there is one) will be tried to be shutdown.
It wouldn't be abruptly shutdown mercilessly closing unsaved documents, would it?
We will be gracefully asked to save those documents.
The Relation Between Multiple Zip Files Cited on This Site
The common build scripts and common build files are included in all the zip files cited on this site. When we expand two zip files in the same directory, should we overwrite the old ones with new ones?
New ones (see the file modification dates) should overwrite old ones: new ones should do fine with any project (if there is no bug in them).
How about utility projects included in multiple zip files?
Well, as they are experimental projects, we modify them frequently, and we don't always preserve the compatibility. If new utility projects break older projects, zip files will have to be expanded in different directories. Or as we replace zip files on this site with updated zip files that adapt to new utilities projects, we can use updated zip files.
That means, the projects in a zip file can include many files irrelevant to the article that cites the zip file.
In fact, that becomes so. Well, you know, it's too cumbersome to remove irrelevant files from each zip file . . .
So, if some irrelevant files are included in a zip file cited by an article, they are for other articles.
Don't we have to erase existing project directories before we expand the zip file when those projects are included in the zip file?
In principle, we have to, because some files could have been erased from those projects in the zip file, although in many cases, not erasing them wouldn't cause any harm.
How to Run a Program
When a project includes a Java main class (a class that has the main method), we can run the program like these as the project directory as the current directory.
For Gradle:
gradle run -PMAIN_CLASS_NAME="<the main class name>" -PCOMMAND_LINE_ARGUMENTS="<the command line arguments>"
For Ant:
ant run -DMAIN_CLASS_NAME="<the main class name>" -DCOMMAND_LINE_ARGUMENTS="<the command line arguments>"
<The previous article in this series | The table of contents of this series | The next article in this series>
