For the latest stable version, please use Spring Shell 3.4.0!

Building

This section covers how to build a Spring Shell application.

Native Support

Support for compiling Spring Shell application into a GraalVM binary mostly comes from Spring Framework and Spring Boot where feature is called AOT. Ahead of Time means that application context is prepared during the compilation time to being ready for GraalVM generation.

Building atop of AOT features from a framework Spring Shell has its own GraalVM configuration providing hints what should exist in a binary. Usually trouble comes from a 3rd party libraries which doesn’t yet contain GraalVM related configurations or those configurations are incomplete.

It is requred to use GraalVM Reachability Metadata Repository which provides some missing hints for 3rd party libraries. Also you need to have GraalVM installed and JAVA_HOME pointing to that.

For gradle add graalvm’s native plugin and configure metadata repository.

plugins {
	id 'org.graalvm.buildtools.native' version '0.9.16'
}

graalvmNative {
	metadataRepository {
        enabled = true
	}
}

When gradle build is run with ./gradlew nativeCompile you should get binary under build/native/nativeCompile directory.

For maven use spring-boot-starter-parent as parent and you’ll get native profile which can be used to do a compilation. You need to configure metadata repository

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.graalvm.buildtools</groupId>
                <artifactId>native-maven-plugin</artifactId>
                <configuration>
                    <metadataRepository>
                        <enabled>true</enabled>
                    </metadataRepository>
                </configuration>
            </plugin>
        </plugins>
    </pluginManagement>
</build>
If you rely on spring-boot-starter-parent it manages native-maven-plugin version which is kept up to date.

When maven build is run with ./mvnw native:compile -Pnative you should get binary under target directory.

If everything went well this binary can be run as is instead of executing boot application jar via jvm.