Main Body START
The Usage of Our Projects Build System Is Explained
About: Java Programming Language
About: UNO (Universal Network Objects)
The Purpose of This Article
-Hypothesizer
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.
-Rebutter
OK.
The Build Environment Has to Have Been Built
-Hypothesizer
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.
-Rebutter
Well, they include also information about other products, but we can ignore irrelevant parts.
-Hypothesizer
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
-Rebutter
You aren't saying that lower versions will never do, are you?
-Hypothesizer
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.
-Hypothesizer
As we cite sample programs archived in zip files, we have to expand the zip file with the directories structure preserved, in a directory.
-Rebutter
We will call the root directory of the expansion 'the development base directory'.
-Hypothesizer
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 . . .
-Rebutter
Before that, I thought, we have to modify some properties in a common build script or a common build file.
-Hypothesizer
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.
-Rebutter
How should we modify them?
-Hypothesizer
'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'.
-Rebutter
Hmm . . .
-Hypothesizer
If the version of LibreOffice is lower that the one we expect, there might be other properties that have to be modified.
-Rebutter
What is the version we expect as the lowest version?
-Hypothesizer
'5.1.4'.
-Rebutter
Hmm . . .
-Hypothesizer
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
-Rebutter
Where can we find target artifacts?
-Hypothesizer
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.
-Rebutter
It wouldn't be abruptly shutdown mercilessly closing unsaved documents, would it?
-Hypothesizer
We will be gracefully asked to save those documents.
The Relation Between Multiple Zip Files Cited on This Site
-Rebutter
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?
-Hypothesizer
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).
-Rebutter
How about utility projects included in multiple zip files?
-Hypothesizer
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.
-Rebutter
That means, the projects in a zip file can include many files irrelevant to the article that cites the zip file.
-Hypothesizer
In fact, that becomes so. Well, you know, it's too cumbersome to remove irrelevant files from each zip file . . .
-Rebutter
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?
-Hypothesizer
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.
-Hypothesizer
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:
@
bash or cmd Source Code
gradle run -PMAIN_CLASS_NAME="<the main class name>" -PCOMMAND_LINE_ARGUMENTS="<the command line arguments>"
For Ant:
@
bash or cmd Source Code
ant run -DMAIN_CLASS_NAME="<the main class name>" -DCOMMAND_LINE_ARGUMENTS="<the command line arguments>"
Main Body END
