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
, ormaven
. 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
andoci
.-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
, orkotlin
. 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
, andvault
.-t, --test=TEST
: Specify which test framework to use. Possible values:junit
,spock
, orkotest
.-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