Introduction

KOS is built entirely around the KAB file format. There’s a lot that could be said about KABs, but for now this article will only serve an introduction. The focus will be on the practical aspects of using KABs; the types, how to make them, and how to organize them within KOS Studio. For a more in depth look at what a KAB is, and the principles behind them please read this article: Everything is a KAB. With that being said, it is time to dive into KABs, starting with the common types that you will encounter.

Kab Types

Every KAB has a KAB type that is used to distinguish its function. For the most part, it is up to the developer to provide their own KAB type. A KAB type can be almost any string, although it is typical that KAB types have a consistent namespace prefix. This is done to avoid possible collisions with KABs from other organizations. This is especially important since Studio functions as a collaborative environment, where developers can share artifacts through the marketplace. For this reason it is common that types are prefixed with the organization name like so; .*. An example KAB type for a ui asset KAB belonging to an organization named “Acme” might be “acme.ui.assets.” All that being said, there are also a number of KAB types that are reserved. These include, but are not limited to

• kos.system
• kos.app
• kos.layer

The first two are reserved for system applications and regular applications respectively, while the last one is used for layer KABs; kabs that function as extensions to the native filesystem. Layers will not be covered in depth here, but will be discussed more in depth in this article: Layer Configuration . Having said that, these are only a small portion of all the reserved types. To view all of the reserved types, please see the javadocs.

Building A Kab

There are two ways to build a KAB in KOS. The first method is to do so manually, using the kabtool. This method is primarily used when you are packaging assets or adapters; pretty much anything that is not a java application. In the case where you are packaging a java application, you can invoke and configure the maven plugin to construct a KAB as part of the maven build process. In either case, you are still using kabtool, only in the latter case you are using it indirectly. Both methods will be shown for the sake of this article.

For those situations where you would like to manually create a KAB, navigate to kabtool; on Mac this should be located within Applications/kosStudio.app/Contents/MacOS/bin. The location of kosStudio.app on other operating systems should be located where you installed Studio. Regardless, if you have not done so already, it is a good idea to add the kabtool to your path, so you wont have to keep navigating to this directory every time you want to use it. To use the kabtool to build a KAB, all you have to do is to run kabtool like so…

$ kabtool -b -t MyType -z /data/MyBuild.zip MyOutput.KAB

This is the most basic way to build a KAB and only requires that you specify the KAB type and contents in the form of a zip file, as well as the name of the KAB file itself. The kabtool offers many more options and operations, though. You can view a list of these operations and option by running kabtool with the help flag like so…

kabtool -h

When building a KAB with the maven plugin the same thing is happening. Our java code is used to create a jar file which is packaged with a descriptor into a zip file. This zip file is then passed to kabtool along with a specified type, in this case kos.system, and used to generate a KAB. Below is the plugin responsible for preforming this operation.

<plugin>
    <groupId>com.kosdev.kos.maven</groupId>
    <artifactId>kos-kab-maven-plugin</artifactId>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>kabtool</goal>
            </goals>
            <configuration>
                <type>kos.system</type> <!-- specify the KAB type -->
                <content>
                    <copy>
                        <includes>
                            <include>descriptor.json</include> <!-- specify descriptor to be included in the zip -->
                        </includes>
                    </copy>
                    <copy>
                        <include>${project.build.directory}/${project.artifactId}-${project.version}-jar-with-dependencies.jar</include>
                        <dir>lib</dir> <!-- where the does the file get zipped here? -->
                    </copy>
                </content>
            </configuration>
        </execution>
    </executions>
</plugin>

Sections

Finally, having covered how to build a KAB, the next step is covering where to put it. Kabs are added to sections in KOS studio. These are found by going to image settings in Studio, accessed via the gear icon next to the image on the Studio main screen. In settings, “Sections” is the top most tab on the left and should be the first thing that pops up when you enter image settings. Shown below is the image sections screen as

Within KOS Studio, sections serve as a way for developers to organize KABs within an image. Developer have the ability to add and remove sections at will, and in situations where you want to remove or add sections without losing them completely, studio provides the functionality to simple disable and enable sections. To do so you can simply click the three dots in the top right hand portion of the section. This will trigger a drop down with an option to enable and disable the section

Moving on to the naming of the sections, there are two thing to keep in mind. The first is that section names have to be unique. For this reason they are namespaced by convention; similar to KAB types. The second thing to keep in mind is that there are certain section names that are reserved or have special properties. Take for instance, the section name kos.system. Just as there must always be a system application for an image to function, that system must always reside in a section called kos.system. Another example of a unique section name would be any name that begins with “kos.autostart.” Sections that use this naming scheme will have their applications automatically launched after the system application has started. Ultimately, sections are a core part of creating any kos image, and knowing how to use them properly is vital for any developer using KOS.