Developing Snaps on Windows via WSL

[ddellsperger]

We recently had a support request received via the support e-mail for snap development and found that the root of the issue (accounts in custom-developed snap packs) was caused by a strange behavior with how Windows (and specifically Windows Subsystem for Linux) sets certain environment variables.  I want to highlight the problem, and the final solution if you are developing snap packs on Windows using Windows Subsystem for Linux.

First, I want to highlight the portions of the pom file for a snap pack where this comes into play.  All of this is happening in the last two plugins for the pom where we're loading the directives file (in your src/main/config folder) to populate runtime properties for the maven antrun plugin to generate a build.properties file (in the target/classes folder) in order to populate certain schema in your bundled snap pack zip file.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <goals>
                <goal>read-project-properties</goal>
            </goals>
            <configuration>
                <files>
                    <file>src/main/config/directives</file>
                </files>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.8</version>
    <executions>
        <execution>
            <id>generate files</id>
            <phase>generate-resources</phase>
            <configuration>
                <target>
                    <!-- This will add the build number and version in the resources file. Don't change the formatting below. -->
                    <echo file="${project.build.directory}/classes/build.properties">
                        build_number=${sl_build}
                        snap_pack_version=${VERSION}
                        snap_pack_fqid=${snap}-snap-${VERSION}-${sl_build}.zip
                        snap_pack_url=$SNAP_HOME/${snap}/target/${snap}-build
                        snap_pack_name=${NAME}
                    </echo>
                </target>
            </configuration>
            <goals>
                <goal>run</goal>
            </goals>
        </execution>
    </executions>
</plugin>

I want to explain what these plugins are doing to better understand the what is happening specifically with Windows via Windows Subsystem for Linux. The first plugin (properties-maven-plugin) is loading your directives file (something like below) and converting it into a "properties" file (where the first word is the key the rest of the line is the property value) so that it can be used in downstream plugins and configurations to inject variables into different items.  The second plugin (maven-antrun-plugin) is then reading properties (from the environment as well as maven and what we loaded in the first plugin) and then writing a file (in this case the build.properties file in target/classes) with certain values which are coming from pom properties (like ${sl_build}, and ${snap}) and others are coming from the directives file (like ${VERSION} and ${NAME})

Example directives file:

NAME Snap Pack Name
VERSION 1
LANG java
ASSET_DIR_PATH /snaplogic/shared

For most systems, this has no issue running, in the end the NAME (snap_pack_name in the build.properties) file gets injected into the schema files and that is what powers the connection between accounts and their respective snaps. Windows (and specifically Windows Subsystem for Linux) however throws a bit of a wrinkle into this.  Windows loads the hostname of the computer into the %COMPUTERNAME% environment variable (see here) for use in scripts. Windows Subsystem for Linux, however sets this to $NAME which is the cause of the clash that brought me to write up this post. All of the maven plugins will prefer the use of the embedded Environment variable settings over the properties pulled in from any files (so if your machine is setting a NAME environment variable, that will be used over the property in the directives file).  The format of the directives file is unable to be changed as it's crucial for the deployment (upload) of the snap pack within your SnapLogic environment.  As a result, there are a few ways to override this, but the easiest would be to force a prefix on the environment variables coming through the directives file.  To accomplish this (and we will be updating our archetype for the August release with these changes), you'll need to update the properties maven plugin to 1.2.1, this will be present in your properties section within the pom file.

<properties-maven-plugin.version>1.2.1</properties-maven-plugin.version>

Then you will need to update your last two plugins (listed above) with the following updated settings and configurations:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <goals>
                <goal>read-project-properties</goal>
            </goals>
            <configuration>
                <files>
                    <file>src/main/config/directives</file>
                </files>
                <keyPrefix>directives.</keyPrefix>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>3.1.0</version>
    <executions>
        <execution>
            <id>generate files</id>
            <phase>generate-resources</phase>
            <configuration>
                <target>
                    <!-- This will add the build number and version in the resources file. Don't
                            change the formatting below. -->
                    <echo file="${project.build.directory}/classes/build.properties">
                        build_number=${sl_build}
                        snap_pack_version=${directives.VERSION}
                        snap_pack_fqid=${project.artifactId}-snap-${directives.VERSION}-${sl_build}.zip
                        snap_pack_url=$SNAP_HOME/${project.artifactId}/target/${project.artifactId}-build
                        snap_pack_name=${directives.NAME}
                    </echo>
                </target>
            </configuration>
            <goals>
                <goal>run</goal>
            </goals>
        </execution>
    </executions>
</plugin>

With these changes, leveraging Windows and Windows Subsystem for Linux to build your project will continue to work as expected.

Thank you for lending me your eyes and attention to potentially help with the development and deployment of your own custom snap packs, feel free to reach out if there are questions regarding snap development!