Plugin

The Intino plugin integrates several tools to facilitate automated software development and deployment. This document provides a detailed overview of Intino’s features, including its core components, supported DSLs, and lifecycle management capabilities.

Main Features

Intino is designed with a range of functionalities. The key features include:

Tara Languages Family Support

Intino provides comprehensive support for the Tara languages family. This includes all DSMLs derived from the Tara mother language. The unified environment developed for these languages offers essential features such as syntax highlighting, early error detection, and code auto-completion. Additionally, it supports version control integration, code generation, and automated refactoring, which collectively enhance the efficiency and accuracy of coding within the Tara language ecosystem.

Archetype and Itrules Integration

Support for Archetype and Itrules. The Archetype language is designed to provide a unified and consistent way to describe the organization of files and directories in a file system, thus facilitating data integration and management across various applications. Itrules is an engine for code generation based on templates, allowing for efficient and standardized development practices.

Application Lifecycle Management with Legio

Legio DSL provides powerful tools for managing the entire lifecycle of applications. It supports dependency management, project structuring, and deployment operations, making it a comprehensive solution for application development and deployment.

Legio

Legio is a specialized DSL of Tara’s family designed specifically to define and manage the project model within Intino. It serves as the backbone for defining the lifecycle. This DSL enables developers to specify and control various elements such as dependencies, build configurations, deployment, and other project-related parameters.

Key Functions of Legio

  • Project Definition: Legio DSL allows developers to clearly outline the structure of a project. This includes defining modules, components, and their interactions, ensuring that all parts of the project are well organized and systematically managed.
  • Dependency Management: Through Legio DSL, projects can efficiently handle dependencies, specifying what libraries or external resources are needed, and managing their versions to ensure compatibility and stability across the project’s lifecycle.
  • Build Configuration: It provides a framework for setting up build processes, including the specification of build steps, required scripts, and other automation processes necessary for compiling and preparing the software for deployment.
  • Environment Specification: Legio DSL allows for the precise definition of environment settings, ensuring that the software behaves consistently in different development, testing, or production environments.

Legio is integrated with the Intino plugin in IntelliJ IDEA, so when Intino projects are created, it automatically incorporates the project and corresponding module configuration files. The creation of this code is guided by code suggestions and features live error checking for both syntax and semantics. This ensures that developers can write code more efficiently and with fewer errors, as they receive real-time guidance and corrections during the coding process.

project.legio

An example of a project configuration is as follows:

Aspects

This project configuration defines a project named “foo-bar” with a detailed description. It includes a developer, John Doe, providing contact and organizational information. The project specifies multiple repositories, each with different release and snapshot URLs for artifact storage. Update policies for repositories can also be defined, such as daily updates for the “iceblue” and “lorem-maven” repositories. Maven central repository is automatically included.

Additionally, the project configuration outlines several server environments (Development, Production, Pre-production) with specific server names, ensuring that deployments are managed across different stages of the development lifecycle.

artifact.legio

In Legio, an artifact is declared for each module of a project, ensuring that each module generates a software artifact. The concept of an artifact is central to the organization and management of the project’s components. Below is a detailed description of the artifact concept and its key elements.

The declaration of an Artifact in Legio serves as the primary definition for a module. It includes several attributes such as groupId, which identifies the group or organization responsible for the artifact, the version which specifies the version of the artifact, ensuring precise version control and management, and description that provides a brief description of the artifact, which is optional and can be left empty. The name of the artifact is necessary and it will be the artifactId in the Maven ecosystem.

License: Legio allows for the specification of a license for each artifact, ensuring compliance with legal and open-source requirements. The type of license can be selected from options such as GPL, BSD, or LGPL.

DSL: The artifact can have associated DSLs (Domain-Specific Languages), which include:

  • Name and Version: These attributes specify the name and version of the DSL.
  • Builder: This optional concept within DSL defines the build process, including attributes like groupId, artifactId, version, and generationPackage. It also allows the exclusion of certain code bases or language generations through specific tags.
  • Output DSL: Defines the output DSL, including its name and any version check mechanisms for runtime and builder libraries, ensuring compatibility and consistency across versions.

Imports: Imports play a critical role in managing dependencies for an artifact. They include:

  • Java Dependencies: This defines the external libraries required by the artifact, managing their versions, and scope (Compile, Runtime, Test or Provided).
  • Web Imports: Specific to web components, this defines web directories, resolutions, and web artifacts needed by the project.

Code and Plugin

The Code concept allows for the specification of target packages for the generated code, while the IntinoPlugin defines various phases such as Export, PostCompilation, PrePackage, PostPackage, and PostDistribution.

The complete metamodel of Legio can be found here.

Application Lifecycle

The lifecycle of artifacts in Legio includes several phases: import, generation, out, pack, local installation (shift + dist), distribution (dist), and deployment (deploy).

Import

In this phase, the dependencies required by the artifact are imported. Legio allows the explicit declaration of all libraries and external resources needed during the project’s development and compilation. This phase ensures that all dependencies are available and correctly versioned before proceeding to code generation.

Generation

During the generation phase, each DSL (Domain-Specific Language) associated with the artifact produces its output. This output can be source code, configurations, or any other type of artifact necessary for the project’s development. Generation is based on predefined templates and rules, ensuring consistency and automation in creating these outputs.

Out

In the “Out” phase, the outputs generated by the DSLs are integrated with the project’s source code. This phase involves compiling all these components together, ensuring that the project is complete and ready for packaging. Integrating the generated outputs with the source code ensures that all parts of the project are synchronized and functional.

Pack

The packing phase (“Pack”) involves bundling all compiled components of the project into a distribution format, such as a JAR or WAR file. This package contains everything needed to run the application, including compiled code, resources, and configurations.

Shift + Dist (Local Installation)

Once packaged, the next step is installing the package in the local repository using the “Shift + Dist” operation. This phase ensures that the packaged artifact is available locally for testing or use by other project modules that may depend on it.

Dist (Distribution)

The distribution phase (“Dist”) involves publishing the artifact to a remote repository. This allows other developers or continuous integration systems to access the artifact for additional testing, integration, or deployment in production environments.

Deploy

Finally, the deployment phase (“Deploy”) involves transferring the packaged and distributed artifact to a specific machine or production environment. This phase ensures that the application is available and functioning in the final environment, ready for end-users.

Each of these phases is designed to maximize efficiency and accuracy in software development and lifecycle management, ensuring that all artifacts are properly managed from creation to final deployment.

Artifact Lifecycle
Last updated on 18 Jul 2024
Published on 18 Jul 2024
 Edit on GitHub