This templateis a Gradle project model for building a Java Server application in the form of an archiving file in ZIP format. This build requires the Adelia objects in this application to be grouped in the form of artifacts generated by an Adelia build project.
Generally speaking, the included artifacts will be JavaServer type (see Table 1 Adelia application area-based build) and produced independently by an application area- or component-based build.
The produced archive is a file in ZIP format containing all the objects from the application configuration.
Creating an Adelia Java Server build project
The project is created by unzipping the %ADELIWS%\Build\templates\adelia java server application.zip file: the obtained 'adelia java server application' directory can be moved and renamed as required.
The Java Server application machine and Adelia build machine may be two different machines. Top of page
Configuring an Adelia Java Server build project
After creating a project, it needs to be configured before it can be executed.
Build project configuration and initialization are based on the settings entered in the gradle.properties file, namely:
General settings
adeliaVersion (mandatory)
Alphanumeric string representing the version number of the Adelia template used to package the application.
version (mandatory)
Alphanumeric string representing the application artifact version number (ZIP). There are several version types:
The release (or final) versions representing the official versions of the application (e.g. 1.0.0),
The snapshot (or instantaneous) versions representing the versions of the application that are under development (e.g. 1.0.1-SNAPSHOT),
The pre-release (or release-candidate) versions representing the versions which are candidates for being final versions (e.g. 1.0.1-RC01).
group (mandatory)
Alphanumeric string representing the identifier of the group or organization instigating the project.
The value follows the same naming rules as Java packages (e.g. com.hardis), and the name of the project's top package is generally chosen as a value.
serverAppName (optional)
Alphanumeric string representing the name of the produced ZIP file.
By default, the name of this file is <project directory name>-<version parameter value>.zip.
If this parameter is entered, the file name will be <serverAppName parameter value>-<version parameter value>.zip.
toolboxDocxToolBx (optional)
Adds the Adelia runtime required to execute DocxToolBx DLL functions to the built application. This manual addition by the user is mandatory when Adelia programs dynamically call these functions (by calling CALL_DLL / CALL_CLASS instructions, where "/", DLLNameorClass and Method_Function parameters are not alphanumeric literals but alphanumeric variables. In the case of a standard call to the DocxToolBx (via CALL_DLL 'DocxToolBx' 'XXX'...), the runtime is added automatically (and this parameter is not taken into account).
This parameter has an alphanumeric value "Y" (runtime add-on) or "N" (no runtime add-on). This parameter is "N" by default.
toolboxXlsxToolBx (optional)
Adds the Adelia runtime required to execute XlsxToolBx DLL functions to the built application. This manual addition by the user is mandatory when Adelia programs dynamically call these functions (by calling CALL_DLL / CALL_CLASS instructions, where "/", DLLNameorClass and Method_Function parameters are not alphanumeric literals but alphanumeric variables. In the case of a standard call to the XlsxToolBx (via CALL_DLL 'XlsxToolBx' 'XXX'...), the runtime is added automatically (and this parameter is not taken into account).
This parameter has an alphanumeric value "Y" (runtime add-on) or "N" (no runtime add-on). This parameter is "N" by default.
toolboxVaToolBxKafka (optional)
Adds the Adelia runtime required to execute VaToolBx DLL Kafka functions to the built application. This manual addition by the user is mandatory when Adelia programs dynamically call these functions (by calling CALL_DLL / CALL_CLASS instructions, where "/", DLLNameorClass and Method_Function parameters are not alphanumeric literals but alphanumeric variables. In the case of a standard call to Kafka functions (via CALL_DLL 'VaToolBx' 'VaToolBxSendToAvroKafkaXXX'...), the runtime is added automatically (and this parameter is not taken into account).
This parameter has an alphanumeric value "Y" (runtime add-on) or "N" (no runtime add-on). This parameter is "N" by default.
toolboxVaToolBxAmqp (optional)
Adds the Adelia runtime required to execute VaToolBx DLL AMQP functions to the built application. This manual addition by the user is mandatory when Adelia programs dynamically call these functions (by calling CALL_DLL / CALL_CLASS instructions, where "/", DLLNameorClass and Method_Function parameters are not alphanumeric literals but alphanumeric variables. In the case of a standard call to AMQP functions (via CALL_DLL 'VaToolBx' 'VaToolBxAMQPXXX XXX'...), the runtime is added automatically (and this parameter is not taken into account).
This parameter has an alphanumeric value "Y" (runtime add-on) or "N" (no runtime add-on). This parameter is "N" by default.
toolboxVaToolBxApe (optional)
Adds the Adelia runtime required to execute VaToolBx DLL Adelia Print Engine functions to the built application. This manual addition by the user is mandatory when Adelia programs dynamically call these functions (by calling CALL_DLL / CALL_CLASS instructions, where "/", DLLNameorClass and Method_Function parameters are not alphanumeric literals but alphanumeric variables. In the case of a standard call to APE functions (via CALL_DLL 'VaToolBx' 'VaToolBxAPEXXX'...), the runtime is added automatically (and this parameter is not taken into account).
This parameter has an alphanumeric value "Y" (runtime add-on) or "N" (no runtime add-on). This parameter is "N" by default.
Repository manager settings
Artifact repositories are used during the following phases when executing an Adelia Java Server build:
In the installation file (ZIP) creation phase, the build uses a repository (download repository) to download the artifacts required to build the installer artifact. These artifacts are:
the Hardis artifact needed to execute the build template,
your own Adelia object artifacts comprising your application: these are generated by the execution of an Adelia build project.
In the final storage phase for the built artifact, a repository (upload repository) can be defined to transfer this versioned artifact.
According to the version type (release or snapshot), the associated repository can be defined.
downloadArtifactsReleaseRepo (mandatory)
Access URL to the download repository of the dependent artifacts needed for the build. This repository should make it possible to access:
Hardis repository artifacts,
your own Adelia object artifacts comprising your application. These artifacts are in release version if you build your application in the release version.
By default, and by way of example only, the value of this parameter is the URL of the repository provided by Hardis.
In its place, in your Nexus, you need to create your own private repository so the Hardis repository and your private repository are grouped together in the release version. Depending on your own Nexus configuration used for your Adelia build projects, it is either the repository created by default by Nexus and called "Releases", or another "hosted repository" with a "Repository policy" set to Release and created by you.
To do this, after logging in to Nexus, in the "Repositories" view, add a new repository defined as a group of repositories described above:
Open the repository definition window via the "Add repository group" command,
From the "Available Repositories" section, add, in the "Ordered Group Repositories" section, the private repository which is a proxy of the Hardis repository as well as the private hosted repository used to store your artifacts in release version.
To finish, replace the downloadArtifactsReleaseRepo parameter value with the "Repository Path" URL of the newly created group repository.
downloadArtifactsReleaseRepo.username / downloadArtifactsReleaseRepo.password (optional)
Defines the user profile and password used to connect to the download repository.
By default, and by way of example, these identifiers are those of the Hardis download repository but they need to be replaced by those of your own group private repository (see downloadArtifactsReleaseRepo above).
When you access this repository in read-only mode, Nexus authorizes an anonymous connection: in this case, leave the "username" and "password" fields blank.
downloadArtifactsSnapshotRepo (optional)
Access URL to the download repository of the dependent artifacts needed for the build. This repository should make it possible to access your own Adelia object artifacts comprising your application. These artifacts are in snapshot version if you build your own application in snapshot version.
NB: Hardis repository artifacts are only available in release version (no snapshot version available).
In your Nexus, you need to create your own private repository so the Hardis repository and your private repository are grouped together in the snapshot version. Depending on your own Nexus configuration used for your Adelia build projects, it is either the repository created by default by Nexus and called "Snapshots", or another "hosted repository" with a "Repository policy" set to Snapshot and created by you.
To do this, after logging in to Nexus, in the "Repositories" view, add a new repository defined as a group of repositories described above:
Open the repository definition window via the "Add repository group" command,
From the "Available Repositories" section, add, in the "Ordered Group Repositories" section, the private repository which is a proxy of the Hardis repository as well as the private hosted repository used to store your artifacts in snapshot version.
To finish, replace the downloadArtifactsSnapshotRepo parameter value with the "Repository Path" URL of the newly created group repository.
downloadArtifactsSnapshotRepo.username / downloadArtifactsSnapshotRepo.password (optional)
Defines the user profile and password used to connect to the download repository. This profile should enable you to access your own private group repository (see downloadArtifactsSnapshotRepo above).
When you access this repository in read-only mode, Nexus authorizes an anonymous connection: in this case, leave the "username" and "password" fields blank.
uploadArchivesReleaseRepo (optional)
Access URL to the upload repository used to store the ZIP artifact built with a release version.
This repository enables the artifacts to be made available in the final version.
uploadArchivesReleaseRepo.username / uploadArchivesReleaseRepo.password (optional)
Defines the user profile and password used to connect to the artifact upload repository in the release version.
uploadArchivesSnapshotRepo (optional)
Access URL to the upload repository used to store the ZIP artifact built with a snapshot version.
This repository enables the artifacts under development to be made available.
uploadArchivesReleaseRepo.username / uploadArchivesReleaseRepo.password (optional)
Defines the user profile and password used to connect to the artifact upload repository in the snapshot version.
Configuring the components of the Adelia Java Server application to build
These components are the Adelia object artifacts generated by the execution of an Adelia build project.
They need to be declared in the Adelia Java Server build project in order to be added to the product installer.
To do this:
open the build.gradle file with a text editor, then
in the "dependencies" section (Declare your artifacts needed to build the Windows application here), declare your artifacts.
JavaServer-type artifacts
These artifacts must be declared by inserting the following instruction:
javaServer group: '<artifact group name>', name: '<artifact file name without version>', version: '<artifact version number>'
Example of declaration of artifact generated by an application area-based build:
For the JavaServer-type artifact with the file name myapp-app_area_1_javaserver-1.1.0-SNAPSHOT.jar, enter runtime group: 'my.company', name: 'myapp-app_area_1_javaserver', version: '1.1.0-SNAPSHOT'.
The group value is that of the "group" setting in the gradle.properties file of the Adelia build project which built the artifact.
Example of declaration of artifact generated by a component-based build:
For the JavaServer-type artifact with the file name prefix_compo_1_javaserver-1.1.0-SNAPSHOT.jar, enter runtime group: 'my.company', name: 'prefix_compo_1_javaserver', version: '1.1.0-SNAPSHOT'.
The group value is that of the "groupId" setting of the component which generates the artifact.
The content of artifacts declared as above is added to the application as follows: The JAR files are copied into the ZIP archive root.
Other artifacts
Other artifacts (in ZIP or JAR format) can be added to the application like, for example, a JavaServer-type artifact containing the .JAVA source files of programs or another containing the file resources required for the application to work and built by a third-party tool (Gradle, Maven or other). In this case, it is possible to, as an example, declare them by inserting the following instruction:
othersResourcesConf group: '<artifact group name>', name: '<artifact file name without version>', version: '<artifact version number>'
othersResourcesConf group: '<artifact group name>', name: '<artifact file name without version>', version: '<artifact version number>', classifier: 'sources'
The 'othersResourcesConf' configuration must first be declared in the 'configurations' closure (declaration to uncomment). The artifact content will be inserted into the application in the 'contentZipAppSpec' closure: this content can either be added at the application root or in a sub-directory (code to uncomment).
Configuration files for the Adelia Java Server application to build
Depending on your application's architecture, some Adelia configuration files may be required to execute it, like the apiva.properties file for example. To add these files to the application, use the Gradle copy directive 'from' to copy these files into the application installation directory (a commented example is given in the build.gradle template provided).
Executing an Adelia Java Server build project
List of Gradle tasks for Adelia Java Server build
clean
Task enabling the objects created when executing msi and zipApp build tasks to be deleted (the build sub-directory is deleted).
zipApp
Launches the archiving file build for the application in ZIP format. The produced file is in the 'build\distributions' sub-directory. Its name is the result of the concatenation of serverAppName and version properties.
This file groups together:
- the content of the project's dependent artifacts (artifacts defined in javaServer, otherResourcesConf configurations),
- the added configuration files (apiva.properties, etc.).
No dependency on Hardis Java runtime artifacts will be copied to the built file. The Adelia Java runtime (as well as the middleware daemon) needs to be previously installed on the "server" machine where this ZIP archive will be deployed.
uploadArchives
This task transfers the built artifact (by calling the zipApp task) to the upload repository.
You must specify the uploadArchivesReleaseRepo or uploadArchivesSnapshotRepo key, depending on the artifact version type.
install
This task transfers the built artifact (by calling the zipApp task) to the repository local to the build machine (local repository in %USERPROFILE%\.m2 directory).