List of Gradle tasks for the Adelia build

adelAppInit

This task initializes the build project by creating the necessary framework to enable artifacts to be generated, based on the list of Adelia application area names declared in the adelLstAppArea key in the gradle.properties file.

The following diagram shows the result of the task with the adelAppName=sampleApp and adelLstAppArea=APP_AREA_1 APP_AREA_2 keys.

The subdirectories, named after application areas, will contain the artifacts for Adelia objects that have private visibility.

Similarly, the _Commons subdirectory will contain the artifacts for Adelia objects that have public visibility.

The following diagram shows the structural details of an "application area name" directory (APP_AREA_1 in this example).

The _Commons directory associated with objects with public visibility has the same structure.

Each "application area name" subdirectory contains a location in which to build the various types of artifacts.

A location may be empty if no objects corresponding to a particular type of artifact exist in the Adelia application area.

adelAppCreateAS400Lib

This task creates (in the environment attributes on the declared AS400) the necessary libraries enabling Adelia objects to be generated in order to build As400Adelia and As400Server artifacts.

The libraries thus created are those defined via the adelGenAS400.as400Adelia.genLib and adelGenAS400.as400Server.genLib keys in the gradle.properties file.

adelAppClean

This task deletes the directory with the name of the application being built, as well as the AS400 libraries specified for the purpose of building As400Adelia and As400Server artifacts (the library names are defined via the adelGenAS400.as400Adelia.genLib and adelGenAS400.as400Server.genLib keys in the gradle.properties file).

The build project is cleared and you must execute the adelAppInit task again to initialize it.

adelAppGenerate

This task launches the Adelia process that generates the objects belonging to the application areas defined by the adelLstAppArea key for the environment defined by the adelEnvName key.

The number of objects generated depends on the generation mode (value of the adelGenIncremental key):

• All objects if Global mode is set,

• Only objects modified since the previous build if Incremental mode is set,

In both modes, if the Adelia generation process returns an error for an object, the other objects are still generated but the build is halted at the adelAppGenerate task.

Note: If an Adelia object generated during a previous build has been removed from the repository, the adelAppGenerate task will not delete the binary objects resulting from the previous generation and those binary objects will be included in the artifact when it is built.

Upon completion of this task, the files produced during the generation process are placed in the following directories:

adelAppBuild

This is the main task in an Adelia build. It is divided into two phases:

1. The adelAppGenerate task is called to execute the Adelia generation process,

2. The files produced by phase 1 are processed to create the related artifacts.

At the end of phase 2, the generated artifacts are placed in the following directories:

For Java artifacts, the .java source files are compiled (by the adelAppBuild task) using the compilation options defined in the adeliws.ini file.

Furthermore, if the value of the build parameter adelCreateSourceFilesArtifacts is Y, 3GL sources artifacts are generated in addition to the main artifacts described above:

 Furthermore, if the value of the build parameter adelGenDebugMod is Y, debug artifacts are generated in addition to the main artifacts described above:

uploadArchives

This task transfers the built artifacts to the upload repository.

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

This task must be called after the adelAppBuild task.

↑ Top of page

Dependency of Gradle tasks for the Adelia build

The following table shows the inputs and dependent tasks for each build task.

Launches a build via a command line

The build is launched in several steps, as described below:

1. Open a DOS command window with an administrator profile,

2. Navigate to the directory containing the build project,

3. Run the following command, based on your choices relating to the generation mode and the storage of artifacts in a repository:

(1)  : adelGenIncremental=N

(2)  : adelGenIncremental=Y

Notes:

• • Calling the adelAppClean task in global mode ensures consistency between the content of an artifact and the generated Adelia objects (for example, if an Adelia object deleted between two builds),
  • If incremental mode is enabled and the adelAppClean task has been executed, the next build executed in incremental mode will have its mode forced to Global instead,
  • As Gradle provides task dependency and task input caching mechanisms, calling the adelAppBuild task will trigger the adelAppInit (project initialization) task in the following cases:
    • When the Adelia build is launched for the first time,
    • If the name of the application to be built (adelAppName parameter) or the list of Adelia application area to be generated (adelLstAppArea parameter) has been changed between two builds.

↑ Top of page

When a build is launched via Jenkins.

The online help is based on Jenkins version 2.66 and the Gradle plugin for Jenkins version 1.27.1.

In a continuous integration approach, Jenkins can be used to run and sequence jobs automatically.

You can define a job as an Adelia build in order to launch it via Jenkins.

There are two ways to do this, as described below.

Adelia build via a command line

When configuring the job, open the Build section and add a step to the build using the "Execute Windows batch command" option. You can enter a series of commands in DOS Batch format, which will then be executed sequentially; for example:

cd /d "D:\build"

call gradlew adelAppClean adelAppBuild uploadArchives

Adelia build via the Gradle plugin

When configuring the job, open the Build section and add a step to the build using the "Invoke Gradle script" option: select the "Use Gradle Wrapper" radio button and then configure the "Wrapper location" field (enter the path to the project containing the gradlew.bat file - in our example, D:\build) and the "Task" field (enter the list of Gradle tasks to be executed - in our example, adelAppClean adelAppBuild uploadArchives).

Additionally, you must specify the build project root directory. To do this, click the Advanced button and specify the "Root Build script" field (in our example, D:\build).

↑ Top of page