This Gradle project template lets you build an Adelia Cloud application as a .WAR file.

This building process requires the Adelia objects used in the application to be grouped together in the form of artifacts produced by an Adelia build project.

Additionally, this template can be used to execute the Adelia Cloud application in Tomcat, via the Gretty plugin (https://github.com/akhikhl/gretty), and to perform integration tests.

These tests must be defined in another Gradle project.

Creating an Adelia Cloud build project

Create the project by decompressing the file %ADELIWS%\Build\templates\adelia cloud application.zip . You can move and rename the resulting adelia cloud application directory as desired.

The workstation used to build the Adelia Cloud application does not have to be the same as the Adelia build workstation.

↑ Top of page

Configuring an Adelia Cloud build project

When you have created a project, you must configure it before it can be executed. Build projects are configured and initialized based on the settings specified in the gradle.properties file, namely:

General settings

adeliaVersion (mandatory)

String representing the version number of the Adelia runtime included in the WAR file that contains the Adelia Cloud application.

This runtime version must be greater than or equal to the version used to generate the artifacts on the Adelia build workstation.

version (mandatory)

String representing the application's version number. Each built artifact will have the same version number. There are several types of version:

• • Release (or final) versions, representing the application's official versions (e.g.: 1.0.0

  • Snapshot versions, representing versions of the application during development (e.g.: 1.0 = 1-SNAPSHOT

  • Pre-release (or release-candidate) versions, representing potential candidates for final versions (e.g.: 1.0 = 1-RC01

group (mandatory)

String representing the ID of the group or organization initiating the project. The value obeys the same naming rules as Java packages (for example, com.hardis). The name of the project's top package is generally used.

appWarName (optional)

String representing the name of the generated WAR file. By default, this file is named <project directory name>-<version parameter value>.war.

If this parameter is specified, the file will be named <appWarName parameter value>-<version parameter value>.war.

openIDSupport (optional)

Add the authentication feature based on the OpenID technology. This parameter has two alphanumeric values: 'Y' (support added) or 'N' (support non added). The default value is 'N'.

↑ Top of page

Gretty settings

Gretty (http://akhikhl.github.io/gretty-doc/index.html) is a Gradle plugin that enables Cloud applications to be executed inside integrated J2EE servlet containers. Gretty supports Jetty (versions 7, 8 and 9) and Tomcat (versions 7 and 8).

By default, the precise versions of Tomcat used are 7.0.78 and 8.0.44, but it is possible to change these version numbers. The task of configuring Gretty (http://akhikhl.github.io/gretty-doc/Gretty-configuration.html) and configuring execution of the Cloud application must be performed primarily in the project's build.gradle file (in this template, Tomcat 8 is configured as the servlet container).

Note: Adelia Cloud applications are compatible with Tomcat versions 8.0.3 and later.

tomcat8Version (optional)

String representing the version number of Tomcat 8 to use (https://archive.apache.org/dist/tomcat/tomcat-8/).

Ensure that any changed version value remains consistent with the value of the tomcat8ServletApiVersion parameter.

tomcat8ServletApiVersion (optional)

String representing the version number of the specification for the Servlet API used by the Tomcat implementation defined by tomcat8Version. This value is given in the table available at the following address: https://tomcat.apache.org/whichversion.html.

↑ Top of page

Integration test execution settings

It is possible to execute the integration tests for the Cloud application after Tomcat has been started. These tests must be defined in the form of a Gradle project, which will be executed when the Cloud application has been started. For more details, refer to the Help page on building integration tests.

pathToIntegrationTestBuildFile (optional)

Defines the path (which may be either absolute or relative to the Adelia Cloud build project directory) of the build.gradle file that declares the tests to be executed.

↑ Top of page

Repository manager settings

When executing an Adelia Cloud build, the artifact repositories are used during the following phases:

• During the WAR file creation phase, the build process uses a repository (the download repository) to download the necessary artifacts to enable the Cloud application's artifacts to be built, These artifacts are:

• • Adelia runtime artifacts required in order to execute an Adelia Cloud application,

  • Your own Adelia object artifacts used in the Cloud application: these artifacts are generated by executing an Adelia build project.

• In the final phase, during which the built artifacts are stored, it is possible to define a repository (the upload repository) to use when transferring these versioned artifacts. Depending on the version type (i.e. release or snapshot), the related repository can be defined.

downloadArtifactsReleaseRepo (mandatory)

URL of the download repository for the dependent artifacts required for the build. This repository must enable access to:

• • Artifacts in the Hardis repository (Adelia Cloud runtime),

  • Your own Adelia object artifacts used in your Cloud application. These artifacts will be a release version if you are building a release version of your Cloud application.

By default, and for example purposes only, this value's parameter is the URL pointing to the repository supplied by Hardis.

In its place, in your Nexus, you must create your own private repository to group the Hardis repository and your private repository in the release version. Depending how you have configured the Nexus used for your Adelia build projects, this may either be the default repository created by Nexus, named "Releases", or else another "hosted repository" created by you with its "Repository policy" set to Release.

To do this, log in to Nexus, open the "Repositories" view and add the new repository defined as a group of the repositories described above:

• • Open the repository definition screen via the "Add repository group" command,
  • In the "Available Repositories" section, select the private repository used as a proxy of the Hardis repository and the private hosted repository used to store the release version of your artifacts, then add them to the "Ordered Group Repositories" section.

End by replacing the value of the downloadArtifcatsReleaseRepo parameter with the "Repository Path" URL of the newly created group.

downloadArtifactsReleaseRepo.username / downloadArtifactsReleaseRepo.password (optional)

Defines the user profile and password used to log in to the download repository.

By default, and for example purposes only, these login details are those used for the Hardis download repository, but you must replace them with the login details for your own private group repository (cf. downloadArtifactsReleaseRepo above). As this repository is accessed in read only mode, Nexus allows anonymous connections. If you want to allow anonymous connections, leave the "username" and "password" fields blank.

downloadArtifactsSnapshotRepo (optional)

URL of the download repository for the dependent artifacts required for the build. This repository must enable access to:

• • Artifacts in the Hardis repository (Adelia Cloud runtime). These artifacts are only available in a release version,

  • Your own Adelia object artifacts used in your Cloud application. These artifacts will be a snapshot version if you are building a snapshot version of your Cloud application.

In your Nexus, you must create your own private repository to group the Hardis repository and your private repository in the snapshot version. Depending how you have configured the Nexus used for your Adelia build projects, this may either be the default repository created by Nexus, named "Snapshots", or else another "hosted repository" created by you with its "Repository policy" set to Snapshot.

To do this, log in to Nexus, open the "Repositories" view and add the new repository defined as a group of the repositories described above:

• • Open the repository definition screen via the "Add repository group" command,

  • In the "Available Repositories" section, select the private repository used as a proxy of the Hardis repository and the private hosted repository used to store the snapshot version of your artifacts, then add them to the "Ordered Group Repositories" section.

End by replacing the value of the downloadArtifcatsSnapshotRepo parameter with the "Repository Path" URL of the newly created group.

downloadArtifactsSnapshotRepo.username / downloadArtifactsSnapshotRepo.password (optional)

Defines the user profile and password used to log in to the download repository. This profile must allow access to your own private group repository (cf. downloadArtifactsSnapshotRepo above). As this repository is accessed in read only mode, Nexus allows anonymous connections. If you want to allow anonymous connections, leave the "username" and "password" fields blank.

uploadArchivesReleaseRepo (optional)

URL of the upload repository used to store WAR artifacts built with a release version. This repository will enable artifacts to be provided in the final version.

uploadArchivesReleaseRepo.username / uploadArchivesReleaseRepo.password (optional)

Defines the user profile and password used to log in to the upload repository for the release version of artifacts.

By default, Nexus allows the use of the Deployment profile (with the username and password values both set to "deployment").

uploadArchivesSnapshotRepo (optional)

URL of the upload repository used to store WAR artifacts built with a snapshot version. This repository will enable artifacts to be provided during development.

uploadArchivesReleaseRepo.username / uploadArchivesReleaseRepo.password (optional)

Defines the user profile and password used to log in to the upload repository for the snapshot version of artifacts.

By default, Nexus allows the use of the Deployment profile (with the username and password values both set to "deployment").

↑ Top of page

Configuring the components of the Adelia Cloud application to be built

These are Adelia object artifacts generated by executing an Adelia build project.

They must be declared in the Adelia Cloud build project in order for them to be added to the generated WAR file.

To do this:

• Open the build.gradle file in a text editor and then,

• Declare your artifacts in the "dependencies" section (Declare your artifacts needed to build the cloud application here).

Cloud / Pojo artifacts

These artifacts must be declared by inserting the following instruction:

runtime group:'<artifact group name>', name: '<artifact file name without the version>', version: '<artifact version number>'

Example of artifact declaration from a build by application area:

For the Cloud artifact with the file name myapp-app_area_1_cloud-1.1.0-SNAPSHOT.jar, you must enter runtime group:'my.company', name: 'myapp-app_area_1_cloud', version: '1.1.0-SNAPSHOT'.

The group value is the value of the "group" parameter in the gradle.properties file of the Adelia build project that built the artifact.

Example of artifact declaration from a build by component:

For the Cloud artifact with the file name prefix_compo_1_cloud-1.1.0-SNAPSHOT.jar, you must enter runtime group:'my.company', name : 'prefix_compo_1_cloud', version: '1.1.0-SNAPSHOT'.

The group value is the value of the "groupId" parameter of the component from which the artifact is produced.

XXServer / CrystalReportsCloud artifacts

These artifacts are not included in the generated WAR file. If you need to execute integration tests on an Adelia Cloud application containing such components, you must deploy them manually prior to execution.

↑ Top of page

Setup files for the Adelia Cloud application to be built

By default, a number of configuration files are supplied with this template. These files are described in the following table:

Some of these files may have been modified by the user during development of the Adelia Web application. The modifications in the files must therefore be propagated from the Web application site to the Adelia Web build project files. They may be propagated either manually or automatically, via the Gradle task named copyWebappConfigurationFilesFromAdeliaCloudsite.

↑ Top of page

Executing an Adelia Cloud build project

List of Gradle tasks for the Adelia Cloud build

copyWebappConfigurationFilesFromAdeliaCloudsite

This task copies the configuration files (cf. table 1 above) from an Adelia Cloud application site. The site's path must be defined by specifying the pathToAdeliaCloudsite parameter in the gradle.properties file.

All configuration files in the Adelia Cloud build project directory are replaced by their counterparts located in the pathToAdeliaCloudsite directory.

This task must be called before the build task

build

This task builds the WAR artifact. The artifact is placed in the build project's build\libs subdirectory.

clean

This task is used to delete the objects created while the build task is executed (the build subdirectory is deleted).

appRunWar (Gretty task)

Starts the configured servlet container (Tomcat 8 by default) and the Adelia Cloud application. To stop the servlet container, press any key in the DOS command window that executed this task (cf. http://akhikhl.github.io/gretty-doc/Gretty-tasks.html).

appStartWar (Gretty task)

Starts the configured servlet container (Tomcat 8 by default) and the Adelia Cloud application. In this case, the appStop task must be executed to stop the servlet container (cf. http://akhikhl.github.io/gretty-doc/Gretty-tasks.html).

farmIntegrationTest (Gretty task)

Triggers execution of the integration tests (if the pathToIntegrationTestBuildFile parameter has been specified).

This task is from the Gretty plugin: the specified servlet container (Tomcat 8, by default) is started, together with the Adelia Cloud application. The integration tests are then executed and lastly, the servlet container is stopped.

If the WAR artifact does not already exist when the farmIntegrationTest task is called, it is created before the task is executed.

uploadArchives

This task transfers the built artifact to the upload repository.

You must specify the uploadArchivesReleaseRepo or uploadArchivesSnapshotRepo key, depending on the version type of the artifact.

↑ Top of page