Module-based approach to an Adelia application

An application is a set of software components (or modules) with shared characteristics, providing and using services (functions, procedures, types, etc.). A software component is a logical representation of the application.

In Adelia, an application is defined in an environment that contains all the application's objects. These objects can be grouped in one or more application areas, each forming a software component.

When the application's binary objects are built, each component is converted into an artifact. An artifact is a deliverable used in a particular version of the application. Lastly, each versioned artifact is saved in a repository via a delivery manager. The role of this repository is to centralize and version all artifacts produced by developers.

↑ Top of page

Adelia objects and related artifacts

Each Adelia application area contains a set of objects of different types (programs, error messages, reports, resources, classes, etc.).

Similarly, when the application is built, each generation platform type produces different types of binary objects. The artifact generation process therefore depends on:

• the Adelia application area,

• the visibility (i.e. public or private) of the object in the application area,

• the Adelia object type,

• the generation platform type.

Each artifact contains the binary objects produced by generating objects of the same type, in the same application area, with the same visibility, for the same generation platform.

The application build process supports the following Adelia object types:

Program objects with the source types:

• Adelia,

• • SAdelia (Adelia server),

  • VAdelia (Visual Adelia Batch and Interactive),

  • WAdelia (Adelia Web Batch and Interactive)

• Class objects,

• Web service objects:

• • DOCUMENT,

  • DOCUMENT_JAXWS,

  • REST

• Crystal Reports Report objects,

• Error Message objects.

The application build process supports the following generation platforms:

• Windows,

• Java (Standard and Cloud),

• AS400

Generated artifact types:

The Gradle automatic artifact builder

Gradle (https://gradle.org/) is an open-source build tool, like Ant and Maven.

These tools are designed to automate IT project building, using a process that can be broken down into a number of tasks, the main steps in which are described below:

• The resource files are prepared, for example by adjusting the property files to suit the target environment (e.g. development, approval or production environment),

• The sources are then compiled (Java, C, C++, etc.),

• These tasks are then executed for the resources and source code of the unit tests,

• The unit tests are then run for the project,

• Lastly, the deliverables (JAR, WAR, EAR, ZIP, etc.) are created, containing the project's binary objects and resources.

In addition to these tasks, other tasks may be required, such as:

• Deploying the generated deliverable, either in a general repository or on an application server (Tomcat, Glassfish, etc.),

• Creating code quality reports ( Sonar , Checkstyle , Cobertura , PMD , FindBugs , JUnit , etc.),

• Generating and deploying the project site.

Gradle can be used to define tasks (and related processes) in a declaratory approach, using a language based on Groovy. A task is defined by:

• its name,

• its type (e.g. Compile, Zip, Jar, Copy, JavaDoc, ProcessResources, Test, etc.),

• its input data/output data (e.g. typed value, file, directory, outputs from another task, etc.),

• its configuration (e.g. source directory, target directory, compilation options, etc.),

• any dependencies on other tasks,

• additional processes other than the default processes defined by the task type.

Together, these tasks form a Gradle project and are declared in a build.gradle file.

It is possible to specify a set of properties and constants for the project, in the gradle.properties file.

Gradle provides a range of plugins enabling users to expand the basic model.

Each plugin adds a specific set of tasks (for example, a Java plugin to compile, test and package Java sources, Maven to implement support for publishing artifacts in Maven-compatible repositories, objective-c to compile Objective-C sources and package native libraries, etc.).

Gradle build projects are executed by running the highest-level task via the gradle taskName command line.

To process this task, Gradle:

1. calculates the dependency matrix of the tasks to be executed (the highest-level task generally defines a set of subtasks as a means of defining modular processes),

2. executes each task in the matrix. If a task returns an error, the build is stopped.

While executing a task, Gradle manages a cache containing its inputs: if the input data is identical to the inputs for the previous execution and the outputs are unchanged, the task is considered to be up to date (upToDate). None of the processes associated with the task are performed.

The following example features a number of Gradle command line entries:

Note: In the rest of the Help, Gradle command line examples use the gradlew command.

Using the gradle command requires the Gradle tool to be installed manually, whereas the gradlew command (supplied in Adelia Studio) performs a silent installation the first time the Gradle tool is used.

↑ Top of page

Application area-based build prerequisites

A number of hardware and architecture constraints apply when executing an Adelia build.

Build workstation prerequisites

The following conditions must be satisfied:

• Adelia Studio must be installed, with the compilation server option (a default installation option), on the workstation running the Adelia build,

• The compatible Adelia environment databases include all database management systems supported by Adelia, with the exception of Access, which does not allow multiple parallel accesses,

• JDK 1.8 must be installed on the workstation.

Continuous integration architecture prerequisites

The Adelia build operation is part of a broader continuous integration approach.

This approach requires delivery managers to be used, to centralize access to and storage of artifacts in repositories. When executing an Adelia build, these repositories are used in two different ways:

1. During the binary object construction phase, the Adelia runtime artifacts required for the compilation operation are retrieved from the (external or remote) Hardis repository,

2. During the Adelia build completion phase, a (personal or local) repository is used to store the built artifacts.

Delivery managers compatible with Maven must be used for this purpose, such as Nexus (https://www.sonatype.com/nexus-repository-oss) or Artifactory (https://www.jfrog.com/artifactory/).

Nexus Sonatype is used in the remainder of this documentation.

To simplify the architecture, it is possible to use a single delivery manager, which can be configured to be compatible with both types of repository used during the aforementioned two phases.

Upon installing Nexus, the following repositories are available by default, accessible via the "Repositories" view:

• The repository named "Central", defined as a gateway (or proxy) to the remote "Maven Central" store: this repository contains a vast array of open-source artifacts (including the artifacts used by the Adelia runtime),

• The repository named "Releases", defined as a local repository in which to store the release version of artifacts,

• The repository named "Snapshots", defined as a local repository in which to store the snapshot version of artifacts.

In this view, a new repository must be added, defined as a proxy for the Hardis remote repository:

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

• In the "Remote storage location" section, enter the URL https://nexus.hardis-group.com/repository/adelia-isv/,

• Leave "Authentication (optional)" unchecked.

• During the Adelia build project configuration phase, the value of the downloadArtifactsRepo key in the gradle.properties file must be replaced with the "Repository Path" URL of the newly-created gateway repository.

Similarly, there are two ways to define the local repositories in which to store the built artifacts:

• Either use the two predefined repositories named "Releases" and "Snapshots",

• Or add two new local repositories (using the "Add hosted repository" command).
  The repository in which the release version of artifacts will be stored must have its "Repository policy" field set to "Release"; the corresponding field in the repository for snapshot versions must be set to "Snapshot".

In both cases, during the Adelia build project configuration phase, the values of the uploadArchivesReleaseRepo and uploadArchivesSnapshotRepo keys in the gradle.properties file must be replaced with the values of the "Repository Path" field of the release and snapshot repositories, respectively.

↑ Top of page