Using the Graal Cloud Native CLI

This guide shows how you can use the Graal Cloud Native (GCN) Command Line Interface (CLI) to generate a project. To install the GCN CLI, see Installing the GCN CLI.

GCN can create the following project types:

Type Command
Application: a server application create-app NAME
Function: a serverless cloud function create-function NAME
Gateway Function: a serverless cloud gateway function create-gateway-function NAME

Where NAME is the name of the application to create.

The synopsis to create a server application, a cloud function, or a cloud gateway function is:

gcn create-app [-ehvVx] \
[--b=BUILD-TOOL] \
[--jdk=<javaVersion>] \
[--lang=LANG] \
[--t=TEST] \
[--clouds=CLOUD[,CLOUD...]]... \
[--features=FEATURE[,FEATURE...]]... \
[--services=SERVICE[,SERVICE...]]... \
[NAME]

The options you can use are:

  • -b, --build=BUILD-TOOL: Specify which Java build tool to use. Possible values: gradle, gradle_kotlin, or maven. If you do not specify the --build argument, Gradle will be used by default.
  • -c, --clouds=CLOUD[,CLOUD...]: Specify one ore more cloud providers. Possible values: aws and oci.
  • -e, --example-code: Generate example code.
  • -f, --features=FEATURE[,FEATURE...]: Include required features.
  • --jdk, --java-version=<javaVersion>: Specify a JDK version the project should target (JDK 17 or higher).
  • -l, --lang=LANG: Specify which language to use. Possible values: java, groovy, or kotlin. If you do not specify the --lang argument, Java is used by default.
  • -s, --services=SERVICE[,SERVICE...]: Define one ore more GCN services to use. Possible values are: auth, database, email, k8s, logging, metrics, objectstore, sdk, streaming, tracing, and vault.
  • -t, --test=TEST: Specify which test framework to use. Possible values: junit, spock, or kotest.
  • -v, --verbose: Use verbose output.
  • -V, --version: Print version information and exit.
  • -x, --stacktrace: Show full stack trace when exceptions occur.

Once you run the command, gcn creates a multimodule project with separate subprojects for each cloud, and a “lib” subproject where you can create classes that are shared between the cloud subprojects. This enables you to separate certain logic that is different between cloud providers, while keeping most of the implementation in the common project.

The [name] of the application (for example, “guide”) determines the name of the directory that contains the project. For example, a Maven project directory structure is as follows:

.
├── LICENSE
├── README.md
├── lib
│   ├── pom.xml
│   └── src
│       ├── main
│       │   ├── java
│       │   │   └── example
│       │   │       └── com
│       │   └── resources
│       └── test
│           └── java
│               └── example
│                   └── com
├── aws
│   ├── pom.xml
│   └── src
│       ├── main
│       │   ├── java
│       │   │   └── example
│       │   │       └── com
│       │   │           └── Application.java
│       │   └── resources
│       │       ├── application.properties
│       │       ├── application-ec2.properties
│       │       ├── bootstrap.properties
│       │       ├── bootstrap-ec2.properties
│       │       └── logback.xml
│       └── test
│           └── java
│               └── example
│                   └── com
│                       └── AwsTest.java
├── micronaut-cli.yml
├── mvnw
├── mvnw.bat
├── oci
│   ├── pom.xml
│   └── src
│       ├── main
│       │   ├── java
│       │   │   └── example
│       │   │       └── con
│       │   │           └── Application.java
│       │   └── resources
│       │       ├── application.properties
│       │       ├── application-oraclecloud.properties
│       │       ├── bootstrap.properties
│       │       ├── bootstrap-oraclecloud.properties
│       │       └── logback.xml
│       └── test
│           └── java
│               └── example
│                   └── con
│                       └── OciTest.java
└── pom.xml