[00:00] In this lesson, we'll demonstrate the steps needed to create a brand new Ignition SDK project framework from scratch. We'll use some available SDK development tools to do this. So we'll show how to obtain and set up those tools. Then we'll run these tools from a command shell, using a command line interface, to set up the files and directories framework for a new SDK project. Our emphasis in this lesson will be on the indicated portion of the development workflow. In prior lessons, we've shown all the steps of this workflow. Now we're circling back around to develop a brand new module from scratch. Here is the general outline of the process to create a brand new SDK project. We'll demonstrate each of these steps in sequence, then present them again along with the key details at the end of this lesson as a one page summary for later reference. Let's get started. So here we are again at the inductive Automation GitHub page. Apart from the SDK training example we used in earlier lessons, IA also provides a suite of tools for the creation of new Ignition SDK modules.

[01:13] So we'll click on the ignition-module-tools repository to copy its URL, and then we'll close this browser window. Here we have a command shell window open to the same location as the file browser above. Then as we did before in a command shell window, we'll do git clone and copy that URL. Then in the file browser above, we see the new ignition-module-tools folder, so we can close this command show window for now. Next, once we have these module tools on hand, we need to first build them from the command line using a Gradle script, so that they can be run. So in my file browser, we will navigate down two levels into ignition-module-tools, then generator, where we can open up another command shell by doing Alt-D cmd, which opens up another command shell.

[02:11] And I'm gonna want to full screen this one. Now we can build the tools using the following command, gradlew.bat clean build. Remember that clean means to clear out any prior compiled files, and freshly recompile them each time. Technically, that clean option is optional here. And here, gradlew stands for Gradle wrapper. There will be lots of intermediate output messages from this build process, so we're going to gloss over all those details, and cut right to the final result, where we are looking to see this Build Successful result. Now we're ready to create a new from scratch SDK module project.

[03:05] Let's first clear the prior outputs by doing cls. Then in the same command shell, still in the generator directory, we'll type the following command, gradlew.bat runCli dash dash console plain. A couple things here before we run this. As before, gradlew means Gradle wrapper. CLli indicates a command line interface, and that IS two dashes ahead of the console option. Once we invoke the script, we'll be asked several project configuration questions as follows. The scope represents whatever combination of gateway, client and designer our new module application will require. Let's create the most general module and specify GCD. The human readable name is how our project will be labeled.

[04:04] It will be used in multiple places in the generated code, as a software identifier and as part of the hook class names. Let's use something generic, yet simple like New SDK Project. For the root package, it's recommended to use reverse domain name notation specific to your organization and project. As an example, let's use something like com.inductive automation. ignition. newsdkproject. Yours of course, will vary. Finally, for the language, this refers to the Gradle build scripts language style. We'll go ahead and accept the default of Kotlin. As you can see, the project creation process is pretty quick, and again, we are looking for this Build Successful message. At this point, we are done with a command shell and can close this window.

[05:09] This is actually a good point to relocate the generated project to a more convenient location. The just generated project will be nested a few levels down, in ignition- module-tools/generator, generator, generator-cli. We can relocate this project by simply cutting it and pasting it to whatever desired location. Here, we've placed it at the same level as the training repository and SDK module tools we imported previously. So our project is ready for further development. We won't build this project, but we've already seen how to do that. So let's at least look over what got created. In an earlier lesson, we examine the overall structure of an Ignition module in some detail. We won't revisit all those specifics here. Instead, let's focus on where our project setup parameters show up in this generated project. Here we've got the project level config file build.gradle.kts open already. We specified a project name of New SDK Project, and we see that here on line 24, and we'll also see that name in several other contexts.

[06:18] On line 29, the resultant module file name, on line 33 in the unique identifier, and in the project browser, in the project name itself, this time lowercased and with dashes. We specified the use of gateway, client and designer scopes at project setup. So here are those three sub-projects. And scrolling down a bit in the config file, here on line 53, here are those GCD scopes we specified. And a little farther down, here on line 77, here are the corresponding hook classes, with the project name incorporated into the class names. As a reminder, at the very end, the skipModuleSigning parameter has a default creation value of false.

[07:09] So we'll probably want to set that to true to allow use of unsigned modules during development. Next, if we expand out the various scope sub-projects, so client source main java, designer source main java, and gateway source main java, we see the three hook classes incorporating the human readable project name as a prefix. And the reverse domain naming we specified is used to set up the directory paths themselves, as well as back in the config file, in the unique identifier. here on line 33. As for the hook classes themselves, starter files are set up using project name and scope naming. The ClientHook file and the DesignerHook file are fairly empty auto-generated boilerplate code.

[08:11] But the GatewayHook file contains much more in the way of empty overridden API functions beyond the initial three lifecycle functions, setup, startup, and shutdown, to help users get going on the creation of their own SDK modules. So at this point, we've got all the basic scaffolding in place to start developing our own new custom SDK module. This is a good juncture to really start digging more deeply into other SDK module code examples, as well as the SDK API itself. Please refer back to the resource links that were given at the end of the first lesson of this course. Okay, let's recap the steps we took to create a new SDK project, with a one page summary reference. Pull over the SDK module tools from the IA GitHub repository, using this git clone command, or if you prefer, the GitHub UI.

[09:08] Then build those SDK tools in the generator subdirectory, using this build command where the clean is optional. Then create an actual new project using this create command. And again, that is a double dash, and supply four project parameters as prompted. That was it. Once our project is created, we can cut and paste it to some desired location. So at this point, we should have everything needed to begin exploring the Ignition SDK API in greater depth and start developing our own Ignition SDK modules. So now what's next? By this point, we have: a development environment, a reliable development workflow, the Ignition SDK API itself, access to some starter example code, and the ability to generate an empty starter module framework. Armed with all these things, we hope you too will be on your way to creating some useful, awesome new Ignition modules. Okay, that's it.

[10:08] Thanks for watching this introductory lesson series on module development with the Ignition SDK.