List of Gradle tasks for the Adelia Component-Based Build

adelCompoSetInit

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

The following diagram shows the result of the task with the adelCompoSetName=sampleApp and adelLstComponents=COMPO_1 COMPO_2 keys.

The sub-directories with Adelia component names will contain the artifacts of Adelia objects contained in each component.

The following diagram shows the structural details of an "component" directory (COMPO_1 in this example).

Each "component" 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 component.

adelCompoSetCreateAS400Lib

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, adelGenAS400.as400Server.genLib, adelGenAS400.language, adelGenAS400.as400Adelia.jobdLib and adelGenAS400.as400Server.jobdLib keys in the gradle.properties file.

adelCompoSetClean

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, adelGenAS400.as400Server.genLib, adelGenAS400.language, adelGenAS400.as400Adelia.jobdLib and adelGenAS400.as400Server.jobdLib keys in the gradle.properties file).

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

adelCompoSetGenerate

This task launches the Adelia process that generates the objects belonging to the application areas defined by the adelLstComponents 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 adelCompoSetGenerate task.

Note: If an Adelia object generated during a previous build has been removed from the repository, the adelCompoSetGenerate 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:

adelCompoSetBuild

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

1. The adelCompoSetGenerate 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 adelCompoSetBuild 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 adelCompoSetBuild task.

Unlike the Adelia application area-based build where the group ID of all the artifacts generated during a build was identical (set with the "group" key in the gradle.properties file), the artifacts built during a component-based build have a group ID from the component they belong to.

↑ Top of page

Link between component dependency and generated artifact dependencies

This section describes how a logical dependency between two A and B components results in artifact build dependencies/POMs generated by the Gradle build tool.

Definition of a dependency

At Gradle level, a dependency between A and B results in an execution dependency between artifacts at generated artifact level.

This is explicitly described in the POM of each artifact generated from A.

The dependency between artifacts is a "runtime"-scope dependency except in the following dependency cases where it is "compile" scope:

• Cloud artifact of A dependent on the Pojo artifact of B,

• CloudEventB artifact of A dependent on the Pojo artifact of B,

• Event artifact of A dependent on the Pojo artifact of B,

• JavaClient artifact of A dependent on the Pojo artifact of B,

• JavaClientWebB artifact of A dependent on the Pojo artifact of B,

• Web artifact of A dependent on the Pojo artifact of B,

• Pojo artifact of A dependent on the Pojo artifact of B,
• WSRest artifact of A dependent on the Pojo artifact of B,
• WSSoapAar artifact of A dependent on the Pojo artifact of B,
• WSSoapJar artifact of A dependent on the Pojo artifact of B.

Like in the Adelia application area-based build, there is dependency between artifacts generated from the same component, namely:

• Cloud artifact of A dependent on the Pojo artifact of A,
• CloudEventB artifact of A dependent on the Pojo artifact of A,
• Event artifact of A dependent on the Pojo artifact of A,
• JavaClient artifact artifact of A dependent on the Pojo artifact of A,
• JavaClientWebB artifact of A dependent on the Pojo artifact of A,
• Web artifact of A dependent on the Pojo artifact of A,
• WSRest artifact of A dependent on the Pojo artifact of A,
• WSSoapAar artifact of A dependent on the Pojo artifact of A,
• WSSoapJar artifact of A dependent on the Pojo artifact of A.

Reminder of the types of generated artifacts:

Client location dependency

Description of a "Client" dependency of component A towards component B in terms of artifact dependencies:

A depends on B

Component B

As400Adelia

As400Server

Cloud

CloudEventB

CloudSelenium

CrystalReportsCloudEvent

CrystalReportsWeb

Event

JavaClient

JavaClientWebB

JavaServer

Pojo

Web

WinClient

WinServer

WSRest

WSSoapAar

WSSoapJar

Component A

As400Adelia

As400ServerAs400Server

Cloud

CloudEventB

CloudSelenium

CrystalReportsCloudEvent

CrystalReportsWeb

Event

JavaClient

JavaClientWebB

JavaServer

Pojo

Web

WinClient

WinServer

WSRest

WSSoapAar

WSSoapJar

The symbol  indicates that the artifact of component A (that defined on the symbol row) depends on the artifact of component B (that defined on the symbol column).

↑ Top of page

Server location dependency

Description of a "Server" dependency of component A towards component B in terms of artifact dependencies:

Client Server location dependency

Description of a "Client Server" dependency of component A towards component B in terms of artifact dependencies:

A depends on B

Component B

As400Adelia

As400Server

Cloud

CloudEventB

CloudSelenium

CrystalReportsCloudEvent

CrystalReportsWeb

Event

JavaClient

JavaClientWebB

JavaServer

Pojo

Web

WinClient

WinServer

WSRest

WSSoapAar

WSSoapJar

Component A

As400Adelia

As400ServerAs400Server

Cloud

CloudEventB

CloudSelenium

CrystalReportsCloudEvent

CrystalReportsWeb

Event

JavaClient

JavaClientWebB

JavaServer

Pojo

Web

WinClient

WinServer

WSRest

WSSoapAar

WSSoapJar

The symbol indicates that the artifact of component A (that defined on the symbol row) depends on the artifact of component B (that defined on the symbol column).

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 adelCompoSetClean 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 adelCompoSetClean 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 adelCompoSetBuild task will trigger the adelCompoSetInit (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 (adelCompoSetName parameter) or the list of Adelia component to be generated (adelLstComponents 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 adelCompoSetClean adelCompoSetBuild 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, adelCompoSetClean adelCompoSetBuild 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