Select a Kernel

Building the Feature file of an Application with the SDK requires a Kernel.

Use one of the following available options to provide it to your project.

Using a Module Dependency

When your Kernel is published in an artifact repository, you can define the Kernel by declaring a module dependency in the build.gradle.kts file, with the microejVee configuration:

dependencies {
   microejVee("com.mycompany:mykernel:1.0.0")
}

Kernel project inside a multi-project

When the Kernel project is in the same multi-project as the component that depends on it (an Application for example), the Kernel project should be declared as a project dependency.

For example if the multi-project contains an Application subproject named my-app and a Kernel subproject called my-kernel, the Kernel project must be declared as a dependency in the build.gradle.kts file of the my-app subproject as follows:

dependencies {

    microejVee(project(":my-kernel"))

}

To find the name of the Kernel project, you can execute the projects task on the multi-project to display all its subprojects, for example:

Root project 'my-multi-project'
+--- Project ':application'
+--- Project ':library'
\--- Project ':my-kernel'

The Kernel Virtual Device and Executable will be automatically built when they are required by the Application. For example the Virtual Device will be built before running the Application on the Simulator (with the runOnSimulator task), and the Executable will be built before building the Application Feature (with the buildFeature task).

Local Kernel project outside a multi-project

When the Application or the Library depending on the Kernel is not in the same multi-project as the Kernel, the Kernel project can be imported using the Gradle Composite Build feature.

This allows the Kernel project to be considered part of the Application project, so all changes done to the Kernel are automatically reflected when building or running the Application.

This is done by adding the following line in the settings.gradle.kts file of the Application project:

includeBuild("[kernel-project-path]")

Then declaring the Kernel as a dependency in the build.gradle.kts file of the Application project:

dependencies {

    microejVee("com.mycompany:my-kernel:1.0.0")

}

The dependency must use the module notation ("group:name:version"), where the group and name match with the ones declared in the Kernel project (the version is ignored). The group is defined in the build.gradle.kts file of the my-kernel project by the group property. To find the name of the Kernel project, you can execute the projects task on the multi-project to display all its subprojects, for example:

Root project 'my-multi-project'
+--- Project ':application'
+--- Project ':library'
\--- Project ':my-kernel'

Using a Local Kernel

When your Kernel has been built locally, you can use its Virtual Device and its Executable by declaring a file dependency in the build.gradle.kts file, with the microejVee configuration:

dependencies {
   microejVee(files("C:\\path\\to\\my\\kernel\\virtual\\device", "C:\\path\\to\\my\\kernel\\executable.out"))
}

This is generally the case when the VEE Port has been built locally

• in SDK 6, by executing the buildVirtualDevice and buildExecutable Gradle tasks on the Kernel project. In this case, the Virtual directory is located in the build/virtualDevice of the project and the Executable is located in the build/application/executable folder.

Warning

It is recommended to include the Kernel project instead of using a file dependency to ensure that any change done to the Kernel project is considered when building your Application without having to manually rebuild the Virtual Device and the Executable.

• in SDK 5, by executing a Build Module on the Kernel project. In this case, the Virtual Device archive file and the Executable are located in the target~/artifacts folder of the Kernel project.

Note

The build.gradle.kts file, as well as other Gradle configuration files, respects the Java properties file convention: the OS path must use the UNIX path convention (path separator is /). The Windows paths must have been converted manually replacing \ by / or by \\.

Resolve a Kernel transitively

Resolving a Kernel transitively is not supported since it causes issues when building an Application on the Kernel.

When a multi-project is composed of Application projects which depends on a Kernel project, the VEE transitivity should be enabled only in the Kernel project for the VEE Port resolution. Therefore, the feature.vee.transitivity.enabled Gradle properties should be set to true in the Kernel project only, for example by defining it in the gradle.properties file of the project. It should not be set in the Application projects.