Created script to automatically create an archive containing the Windows

[xbarrelet]

You can now use a script in the folder windows-installer to create an zip archive that contains:

• Our application
• The windows service installer with its xml configuration
• A bat script that takes care of the installation and start of the service
  For now the instruction are to extract this archive in Windows under c:\ere-ps-app and run the bat file.
  The instructions reside in windows-installer/README.md.
  Tested on my Windows 10 partition, service still works after restart.

[cartel1]

@barelyThinkingBagOfWater Don't change the application.properties file just yet. We need to do a harmonising exercise later on these config items as certain aspects of the application are currently working with it as is and all tests are passing the last time I checked.

I've invited @OmarMalass to assist with this review as well as both of you have some overlap on this task.

[ManuelB]

@barelyThinkingBagOfWater the code looks quite good to me. Especially running the app as windows service is an awesome feature.

@barelyThinkingBagOfWater can you ping me if it takes longer than 3 days to merge this?

We are on a very tight timeline and we have to make sure to integrate code in a fast way.

My personal opinion is, that architecture review before any code is written makes a lot more sense than code review.

[OmarMalass]

As this is related to the installer, I'll write a short description of the current state of the installer before writing my comments.

A brief background and the current installer-state

1. We used Launch4j to create a .exe file based on the .jar file. This allows us enables us to create a .exe executable instead of a .jar file. Using Launch4j, we can also do JRE-bundling.
2. We used NSIS to build the installer. Using NSIS, we can run a script/bash after installing. So that means we can configure NSIS to run the installer.bat script automatically as a part of the installation process.

My comments on the pull request:

Testing the script:

I ran the createWindowsInstaller.sh script on windows. It copied the build directory but didn't create a zip file. So I did the steps manually. I added the .bat, .exe. .xml files manually into the build directory (target/quarkus-app), moved the files to a directory matching the path in the .xml files. I ran the .bat file and it installed the app as a service on Windows successfully.
However, it didn't run. I tried to start it manually from Windows services, but I got "The process terminated unexpectedly".

Is the .exe file important? Can the service installation process be done entirely in a bat file?

Currently, you run the bat file, which starts the .exe. Is there a way to make everything compact in the .bat file? I suppose this way it would all be contained in the .bat file.

Replacing the hardcoded path in .xml

Can we make the path in .xml dynamic or relative instead of static? I can think of two ways:

• Dynamic: As I mentioned earlier, we might be able to make the installer run the bat file automatically, this way, we can make the installer pass the directory path to the .bat file instead of hardcoding it in the .xml file.
• Relative: Since the .bat file is in the build directory, we can also make the .bat file use its working directory as a relative path to the .jar file.

Files affected in the commit:

Can you keep the committed changes in the branch limited to what's related to the installer?

Thank you!

[xbarrelet]

The script is made to be run on Linux as I work on Ubuntu, it won't work on Windows (only in WSL). If you have Java installed on Windows (I forgot to add this as a prerequisite) and you put it in the correct path it will work. You can check the service log to see what's happening on your side I surmise.

The exe file is important as it creates and then starts the service, the bat script just runs it with the correct parameters to simplify the commands.

I'll make the path dynamic then with some scripting.

About the application properties : I just removed the environment variables hardcoded in it as anyway the env variables can override the local variables if you use the correct name (ENV_FOO will automatically override env.foo as with Spring and Micronaut) but I understand your concern and will let these files as they were before.

[xbarrelet]

Now the path is dynamically resolved during installation, you can extract the archive anywhere.
I reverted application.properties and DirectoryWatcher to their last state.

[OmarMalass]

Tested it, the service was installed and it works great.
Is it possible to configure the service installer to run the jar wrapper (which will be a .exe) instead of the jar itself?
From my point of view I have one final edit request before merging: can you remove the @Disabled annotations from the tests? We can skip the tests in the packaging process for now.

[xbarrelet]

We can always in the future put the wrapper exe in the part with the $PATH template variable before and remove the argument part in the xml configuration file. I can take care of it if you want when the wrapper will be ready.
I removed the annotation as asked.

[OmarMalass]

Final conclusion before merging:

To set the wrapper as the executable, we update the configuration in the .xml file instead of the .jar file

<executable>java</executable>
<arguments>-jar "$PATH\quarkus-app\quarkus-run.jar"</arguments>

Since the wrapper is not available in the main repo at the time, we will keep the executable pointing at the jar file.