Retrieving the Raspbian OS image

We will use Trixie as a starting point.  You can find all available Raspberry Pi images on this page:

https://www.raspberrypi.com/software/operating-systems/.

To download Trixie, us this link: 

https://downloads.raspberrypi.com/raspios_lite_armhf/images/raspios_lite_armhf-2026-04-21/2026-04-21-raspios-trixie-armhf-lite.img.xz

For my purposes, I've downloaded the 32 bit version of Trixie.

Installing the image on an SD card

Once the image is downloaded, use 7zip to extract the "pure" .img file.  Once this is done, take a (new) SD card and put it in the Windows PC.  Be aware that the content of the SD card will be completely wiped out, if no new SD card is used!

Next, use Win32DiskImager to flash the .img file on the SD card.  Make sure you're selecting the correct drive letter in Win32DiskImager

Activating the SSH daemon

Since a couple of years, the SSH daemon is not activated anymore by default for all the Raspberry Pi images.  This is done for security reasons.

To be able to activate the SSH daemon, pls. follow the procedure explaind in this section: Raspberry Pi changed its login process.

Starting up the Raspberry Pi for the first time

Once the necessary and empty file ssh is on the SD card and you've prepared the file userconf.txt with the user name and the encrypted password you can put the SD card in a Raspberry Pi.

Once you start up the Raspberry Pi, use Putty to set up an SSH connection with the Raspberry Pi.  Therefore, you have to know the IP address assigned to the Raspberry Pi and you can use the modem of your ISP to check what IP address is assigned.

Once the SSH connection is established, the Putty command window will ask for the user name and login password.  Pass those credentials to have an initial Raspberry Pi start up.

Run raspi-config to set initial things

Once you're logged in, you have to run the raspi-config application as sudo (!!!) to activate the SSH daemon "forever" (remember, preparing the SD card with the ssh file name and the userconfig.txt file is to only start up the SSH daemon once, until it's been taken over by the setting in the raspi-config application).

Modify the following configurations (reboot if asked to do so):

• Interface options (option 3)

  • SSH: Yes

  • SPI: Yes

  • I2C: Yes

  • 1-wire: Yes

• Localisation Options:

  • Timezone: Europe -> Brussels

• Advanced Options:

  • Expand Filesystem

This should be OK for now.

Perform changes and add tools to the Raspberry Pi

• Change the hostname: sudo hostnamectl set-hostname <new_hostname>.  Only valid after a reboot.

• If needed, adapt IP address in the DHCP list of the modem to suite your needs.

• No need anymore to install build-essential on a Trixie-based OS: it's already installed.

• Install Git: sudo apt install git

• Install plocate: sudo apt install plocate (fast search tool)
  See this website for more info about plocate.

• Install i2cdetect: sudo apt install i2c-tools

• Install vim: sudo apt install vim -y

  • Add .vimrc file for text formatting (see example .vimrc file)

• Setup password-less access from:

  • Windows, using Putty key (ED25519)

  • WSL2, using OpenSSH key (ED25519)

  • Git Bash, using OpenSSH key (ED25519)

• Modify .bashrc file:

  • Add aliases and more (see example in this section) 

• Add mystuff directory

• Clone WiringPi and build it: 

  • Go to ~/mystuff

  • If wiringPi would be present from a previous installation, remove it first:

    • sudo apt-get remove wiringpi -y 

  • Run git clone https://github.com/WiringPi/WiringPi.git wiringPi: this will put the wiringPi files into the directory wiringPi

  • cd into wiringPi

  • Run the command sudo ./build (sudo ./build clean if you want to clean the generated files first)

  • wiringPi will be installed in /usr/local/lib and links to this location will be generated in /usr/lib.

• Install JDK11:

  • On a Windows PC, fetch the download from https://www.azul.com/downloads/?package=jdk#zulu

  • Download the source files for JDK11, Linux, ARM 32-bit HF, JDK:
    https://www.azul.com/core-post-download/?endpoint=zulu&uuid=d5b7dfc9-8fba-4e12-946c-38efd6efcd96
    As of this writing (April 29, 2026) the filename is zulu11.86.21-ca-jdk11.0.30-linux_aarch32hf.tar.gz

  • Use WinSCP to copy the file from Windows to ~/mystuff/azulzulu on the Raspberry Pi (make azulzulu directory first)

  • Untar the .tar.gz file: tar -xzf zulu11.86.21-ca-jdk11.0.30-linux_aarch32hf.tar.gz

  • Check if there's already a directory /usr/lib/jvm.  If not, create it: sudo mkdir -p /usr/lib/jvm

  • Copy the directory to /usr/lib/jvm.  While copying it, rename it to zulu11:
    sudo cp -R zulu11.86.21-ca-jdk11.0.30-linux_aarch32hf /usr/lib/jvm/zulu11 

  • Register this JDK version with update-alternatives; do this for java as well as for javac:

    • sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/zulu8/bin/java 1 

    • sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/zulu8/bin/javac 1 

  • Select this version of Java as the default Java.  If there's no other Java version already installed and registered, it will automatically be chosen:

    • sudo update-alternatives --config java => select the zulu11 entry (will be 0 for auto mode, 1 for manual mode if no other JDK's are installed)

    • sudo update-alternatives --config javac ==> select the zulu11 entry (same here...)

  • If you now type java --version on the command line, you should see something like this:
    pi@rpi-44:~/mystuff/azulzulu $ java --version
    openjdk 11.0.30 2026-01-20 LTS
    OpenJDK Runtime Environment Zulu11.86+21-CA (build 11.0.30+7-LTS)
    OpenJDK Client VM Zulu11.86+21-CA (build 11.0.30+7-LTS, mixed mode)

  • 
    
    

I'm using AzulZulu to get my JDK versions.  I'm avoiding Oracle and relying on a truly free distribution of JDK.

The download section on the Azul website can be found here: https://www.azul.com/downloads/#downloads-table-zulu.

You can select the version, OS, architecture and package.

I've selected Java 11 (LTS), Windows, x64 64-bit and JDK as options.  In the Download drop-down box, I've selected .msi so that the Windows installer is used to install the Java JDK version.

To make sure JDK11 is taken as default Java version (can be checked by running java -version on a DOS command line), I did the following:

• creating an environment variable JAVA_HOME and point it to the installed Java directory (in my case, ending with .\jdk11.0.12 as of this writing)

• add %JAVA_HOME%\bin as the first item in the Windows Path variable

Next to this, I've also created batch files so that I can quickly, but temporarily, switch to another JDK if need be.  For JDK11, for instance, this is the content of the batch file java11_azul.bat:

@echo off

set JAVA_HOME=D:\WinApps\Programming\Java\AzulZulu\jdk11.0.12

set Path=%JAVA_HOME%\bin;%Path%

echo Java 11 - Azul Zulu is activated.

sleep 1

TITLE Java 11 - Azul Zulu

cls

Similar batch files exists for JDK8 and JDK14.

The path to those batch files is also integrated in the Windows Path variable so that I can run those batch files from everywhere I have opened a DOS command box.  Again, note that this JDK selection is only temporarily!

The Pi4J project uses Maven as build process.  At least Maven 3.8.2 has to be installed on the Windows PC.

The current Maven release is 3.9.15 and can be downloaded here: https://maven.apache.org/download.cgi.

I've chosen the .zip file: https://dlcdn.apache.org/maven/maven-3/3.9.15/binaries/apache-maven-3.9.15-bin.zip.

Once you downloaded the zip file, unzip it somewhere on your PC.

Once this is done, make sure:

• you create an environment variable M2_HOME and assign it the location of the bin directory

• you create an enivironment variable MAVEN_HOME and assign it the location of the bin directory

• you add the Maven bin directory also to the Windows PATH variable

To check if Maven can be found from everywhere, open a DOS command box at a random directory location and run the command mvn -version.

You should see the following feedback:

C:\Users\Geert>mvn -version

Apache Maven 3.9.15 (98b2cdbfdb5f1ac8781f537ea9acccaed7922349)

Maven home: D:\WinApps\Programming\maven\apache-maven-3.9.15

Java version: 11.0.12, vendor: Azul Systems, Inc., runtime: D:\WinApps\Programming\Java\AzulZulu\jdk11.0.12

Default locale: en_US, platform encoding: Cp1252

OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Once this is in place, you will be able to build the Pi4J project.

Pi4J - v1.x is not maintained anymore.  It's now an archived repository on GitHub.

On the official website of Pi4J, however, you can still find information about and retrieve the older repositories.  To fetch those, go to this page:
https://www.pi4j.com/about/info-v1/

On that page, you will find a link to the GitHub repository for v1.  

This is the link to the GitHub repository:
https://github.com/Pi4J/pi4j-v1

You can stick to the master branch or you can select the v1.4 branch.  The only difference is some administration stuff that has been updated since the official release of v1.4.

Note that v1.4 needs JDK11 instead of JDK8.  v1.4 won't compile anymore with JDK8 since API's are used that are only available since JDK11. 
One such API is ProcessHandle, used in
.\pi4j-v1.4\pi4j-core\src\test\java\com\pi4j\io\file\test\LinuxFileIntegrationTest.java.  

See the JDK documentation about ProcessHandle.  You will see it's been introduced since JDK 9 but the Pi4J website clearly mentions JDK11 has to be used.

Missing subfolders

In the introduction above, I mentioned that v1.4 does not contain two - for me, at least - very important subprojects:

• pi4j-device 

• pi4j-gpio-extension 

Those were two brilliant libraries that containt fully working code to control devices (buttons, switches, ...) and GPIO extensions (IO-expanders, DAC's, ADC's, serial communication,...).  A real pity they're gone.  Especially since I use one of the GPIO extension drivers: MCP23017.  Also listeners are used in my HomeControl project.

A big mistake to leave them out, if you ask me.

Getting them back

However, although v1.4 does not have those subprojects anymore, it doesn't mean you can't add them again locally!  That's exactly what I did.

To get those missing subprojects, select release 1.3 as release in the Git repository for the time being.  This will put back both missing subfolders, which you can put aside for the moment (that is, move those directories out of the standard pi4j-v1.4 repo structure and put them somewhere apart).

To know later on that those subfolders came from a v1.3 release, I postfixed those subfolders with -v1.3 like so:

• pi4j-device-v1.3 

• pi4j-gpio-extension-v1.3 

This way, I can always look back and see what version those two subfolders were taken from.

However, I came to know that this is not the best way forward. 

Further down this article series, I will explain how to bring those two missing packages into the pi4j-distribution tar files.  If you want to do this, you have to follow the maven rules.  

Since packages are referred to by their names on a website called https://repo.maven.apache.org/maven2 and since Pi4J has put those packages to that site under the names pi4j-devices and pi4j-gpio-extension and not under the names pi4j-devices-v1.3 and pi4j-gpio-extension-v.13, the maven build will fail.

So, do NOT rename the two packages, leave their names "as is":

• pi4j-device 

• pi4j-gpio-extension 

Once you have put the 2 subfolders aside, go back to the latest commit for Pi4J - v1.4.

Check the "pure" v1.4 build

Once you're back to the v1.4 branch it's best to test out v1.4 only and see if everything is still building.  I've installed Git Bash to have a Linux-alike environment, so that I can run shell scripts.  Using xplorer2, I can open a Git Bash session directly in the Pi4J Git repository directory.

To make things easy, I created a build script build.sh with the following content:

#!/bin/bash

export JAVA_HOME=D:/WinApps/Programming/Java/AzulZulu/jdk11.0.12

echo "Java version:"

java -version

echo "Maven version:"

mvn -version

echo "Building..."

mvn clean install -DskipTests

Run the build.sh script, it will take a while.  If that is still successful, we can do the next step.

Bringing them into the Pi4j-v1.4 realm

The next step is to copy the 2 subfolders set apart next to the pi4j-core and other subdirectories.  In the end, the directory structure should look something like this:

.\pi4j-core
.\pi4j-device
.\pi4j-distribution
.\pi4j-example
.\pi4j-gpio-extension
.\pi4j-native
.\src

It's now just a matter of taking the two new subdirectories into account in the overal pom.xml file.  To do this, open the pom.xml file and search for the line
<!-- PROJECT MODULES -->

In there you will see the 3 existing modules:

• pi4j-core 

• pi4j-example 

• pi4j-distribution 

Just add the two extra subfolders to that list.  The end result should be something like this:

<!-- PROJECT MODULES -->
<modules>
<module>pi4j-core</module>
<module>pi4j-example</module>
<module>pi4j-device</module>
<module>pi4j-gpio-extension</module>
<module>pi4j-distribution</module>
</modules>

I've highlighted the new ones in bold blue.  As you can see, the two extra packages are added before the distribution package.  This has a reason, since I want the extra packages be part of the overall pi4j-distribution package.

Building with the newly added subfolders

If you now build the whole repository again using the build.sh script, the new subfolders will be taken into account during the build process.

This should be the end result when  all is successful:

main:
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Pi4J :: Parent POM 1.4 ............................. SUCCESS [  1.250 s]
[INFO] Pi4J :: Java Library (Core) 1.4 .................... SUCCESS [ 14.896 s]
[INFO] Pi4J :: Java Examples 1.4 .......................... SUCCESS [  5.381 s]
[INFO] Pi4J :: GPIO Extension 1.3 ......................... SUCCESS [  6.339 s]
[INFO] Pi4J :: Device Abstractions 1.3 .................... SUCCESS [ 10.624 s]
[INFO] Pi4J :: Distribution 1.4 ........................... SUCCESS [  4.280 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  44.270 s
[INFO] Finished at: 2026-04-26T19:07:46+02:00
[INFO] ------------------------------------------------------------------------

Also here I've highlighted the "newbies" in bold blue.

Where is the result stored?

Once the overall build is done, we should be able to find all the build results for each and every "task" the build process has executed.

1. Core and Example files

The result of the core library is located in  .\pi4j-distribution\target.
In there, you have a .deb, .tar.bz2, .tar.gz and .zip file for pi4j-1.4.

If you for instance open the .zip file, you will see a lib library which will contain  the following .jar files:

1. 1. pi4j-core.jar 

   2. pi4j-core-javadoc.jar 

   3. pi4j-core-sources.jar 

   4. pi4j-example.jar 

   5. pi4j-example-javadoc.jar 

   6. pi4j-example-sources.jar 

So, for each subdirectory, we have the real code, the JavaDoc info and the source files.  Especially the last file can come in handy during debug sessions.

Note that you can find the same files also "straight" located in .\pi-distribution\target\distro-contents\lib.  The content of distro-contents is used to create all the above compressed files.

The choice is up-2-you!

2. Device and Extenstion files
   
   The resulting files of the newly added subfolders are located into their own .\target directory inside each subfolder separately.  There's no compressed folder generated: the source, JavaDoc and core .jar files are just their, in plain.

Bring the extra packages into the distribution mechanism

It would be nice to have all packages into the pi4j-distribution target isntead of spread around over different subfolders.

This can be achieved, but therefore some changes have to be done in a few pom.xml files.

1. Parent pom.xml file
   
   In the parent pom.xml file, we already added the two extra packages pi4j-device and pi4j-gpio-extension so that they are taken along while building the Pi4J repo.
   
   However, the result of this is that the resulting code, javadoc and source files are located in the .\target directory of those two packages and not in the .\target directory of pi4j-distribution.
   
   To be able to do this, we have to add two "own" properties into the parent pom.xml file:
   - pi4j.version => will be assigned the value 1.4
   - pi4j.version.legacy => will be assigned the value 1.3
   
   Why is this?  Maven has well-defined keywords that can be used in a pom.xml file.  You can't just like that add new keywords, they won't be understood by the Maven build mechanism.  Unless you add them into the <properties> section.
   In that section, you can add whatever keywords you want and they can be used in child pom.xml files, if needed.
   
   Also, during the build process, a link is made to the website  https://repo.maven.apache.org/maven2.   If you go to that website, you will see a zillion of subdirectories.  One of them is com.
   If you go inside com, you will find pi4j.
   If you go inside pi4j, you will find a lot of Pi4J subdirectories, one of them being pi4j-device.
   If you go inside pi4j-device, you will find  subdirectories represented by version numbers; one of them is 1.3
   
   This is why we assign value 1.3 to the property pi4j.version.legacy (see above) so that the build process can find back that version of the modules on the Maven webside.
   On that website, you also see that 1.3 is the latest version, there's no version 1.4 anymore.
   
   Note that the same is valid for pi4j-gpio-extension.  See for yourself.
   
   The other modules pi4j-core, pi4j-example and pi4j-distribution do have a version 1.4, hence we assign 1.4 to the property pi4j.version (see above).
   
   

2. Child pom.xml file
   
   The child pom.xml file of concern is the one of pi4j-distribution.  There's a section called <dependencies> and this section already contans the core, sources and javadoc dependencies for pi4j-core and pi4j-example.
   
   Since we now have a property pi4j.version defined in the parent pom.xml file, we can use ${pi4j.version} here instead of the ${project.version} property defined in the parent pom.xml file. 
   Not that the current implementation is wrong, but we will now add the missing two subprojects to the <dependencies> section and those will be using ${pi4j.version.legacy} as placeholder for the version 1.3 for those subprojects.
   
   To have the same "look'n'feel" in the <dependencies> section, I prefer to use pi4j.version and pi4j.version.legacy instead.
   
   The <dependencies> section of the child pom.xml file looks like this now:
   
   

<!-- PROJECT DEPENDENCIES -->

<dependencies>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-core</artifactId>

<version>${pi4j.version}</version>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-core</artifactId>

<version>${pi4j.version}</version>

<classifier>sources</classifier>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-core</artifactId>

<version>${pi4j.version}</version>

<classifier>javadoc</classifier>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-example</artifactId>

<version>${pi4j.version}</version>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-example</artifactId>

<version>${pi4j.version}</version>

<classifier>sources</classifier>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-example</artifactId>

<version>${pi4j.version}</version>

<classifier>javadoc</classifier>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-device</artifactId>

<version>${pi4j.version.legacy}</version>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-device</artifactId>

<version>${pi4j.version.legacy}</version>

<classifier>sources</classifier>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-device</artifactId>

<version>${pi4j.version.legacy}</version>

<classifier>javadoc</classifier>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-gpio-extension</artifactId>

<version>${pi4j.version.legacy}</version>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-gpio-extension</artifactId>

<version>${pi4j.version.legacy}</version>

<classifier>sources</classifier>

</dependency>

<dependency>

<groupId>com.pi4j</groupId>

<artifactId>pi4j-gpio-extension</artifactId>

<version>${pi4j.version.legacy}</version>

<classifier>javadoc</classifier>

</dependency>

</dependencies>

The modified version references are given in blue, the newly added subdirectories are given in red.

If you now run the build.sh script you will see that the new subdirectories are now part of all zipped files in pi4j-dependencies\target.

This is what I tried to achieve!

I want to use NetBeans as my IDE for my HomeControl project, since that's the only IDE I know that allows you to remotely debug on the Raspberry Pi.  For free, that is...

I learned the hard way that NB12.6 is the highest possible version I can use to cooperate with my HomeControl project.  Among others, one of the reasons is that Nashorn is not supported anymore from NB15 onwards.  Nashorn is a kind of scripting language, needed if you want to remotely debug your application from NetBeans (not needed if you only want to run your application using NetBeans).

NetBeans 12.6 can be downloaded here: https://netbeans.apache.org/front/main/download/nb126/nb126/.

Once it's downloaded, install it somewhere on your PC.

• The NB cache is saved in C:\Users\<user>\AppData\Local\NetBeans\Cache.  This is done for every version of NB you've installed on your PC in the past.

This section describes the steps to create a remote connection between NetBeans 12.6 and Raspberry Pi.

Remote Java SE

• Make sure the Java SE plugin is installed.  You can check this with Tools -> Plugins -> Installed and search for Java SE.  If not present, select the Available Plugins tab and search for the Java SE plugin.

Overview of existing Java Platforms + adding new remote RPi session

• Select Tools -> Java Platforms: you will see an overveiw of Java SE and Remote Java SE platforms (if any) in the left list box.
  To create a new remote session to a RPi, do the following:

  • Click Add Platform...

  • In the new dialogue box, select Remote Java Standard Edition

  • Press Next

  • In Platform Name, give it a suitable name.

  • In Host, pass the IP address

  • In Username, past pi (or whatever user name you've given)
    Note that the field Working Dir (see further) will be filled in automatically.
    The default directory is /home/<username>/NetBeansProjects.

  • Select Use Key Authentication to be able to connect password-less

  • In Key File, browse to the location where the private key is.
    Note that NetBeans cannot handle ED25519 keys!
    Note that NetBeans 12.6 can't handle Putty .ppk files anymore (used to work in NetBeans 8...)!
    You have to convert the .ppk key to an OpenSSH key:

    • Open PuTTYgen

    • Select the RSA private key .ppk file

    • Select Conversions from the menu

    • Select Export OpenSSH Key: ignore the request for a passphrase

    • Give it a filename without extension

  • Select the converted .ppk to OpenSSH private key when browsing for the Key File

  • In Remote JRE Path, add the path to the JDK installation on the RPi.
    Example: /usr/lib/jvm/zulu11

  • Working Dir: should already be filled in automatically, the moment you passed the username to the system.
    Can be overruled, if you like.

  • Click Finish: NB will now try to set up a connection and - if successfull - will also create the working directory.  If all goes fine you will get a confirmation.

VERY IMPORTANT: from Bookworm onwards, RPi doesn't accept RSA-SHA1 keys anymore

When I tried to connect from NB 12.6 to my RPi running Trixie using my normal connection method, RPi constantly refused my key.  The feedback I got on my NB terminal was telling me the authentication failed all the time.

Asking Copilot, I came to know that from RPi Bookworm onwards, there's no support anymore for RSA-SHA1.  At least not by default.

Solution to the problem:

• • As sudo, open the file  /etc/ssh/sshd_config

  • Add the following two lines of code:
    PubkeyAcceptedAlgorithms +ssh-rsa
    HostkeyAlgorithms +ssh-rsa

  • Restart SSH:
    sudo systemctl restart ssh

  • Now you should be able to create a working remote session from NB12.6 to the RPi running Trixie and/or Bookworm.

Testing an existing remote session

If you have already set up a remote session, it's always possible to test the connection at every moment.  When the Java Platform manager is open, select the remote session you want to test and click the button Test Platform.  The same test sequence will be executed as the one that was ran the moment you set up the remote session for the first time.

If all is fine, you will get a successful confirmation.

Before you can start a remote debug session, there's a few things that are important.

NetBeans has its quirks

When I was starting a remote debug session on a RPi from NetBeans, I always got the following error (see also this section):

cmd : cd '/home/pi/NetBeansProjects//HomeControl_NB12.5'; '/usr/lib/jvm/zulu11/bin/java'  -Xrunjdwp:transport=dt_socket,address=demosite.local:15457 -Dfile.encoding=UTF-8   -jar /home/pi/NetBeansProjects//HomeControl_NB12.5/dist/HomeControl.jar

ERROR: transport error 202: getaddrinfo: unknown host
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)

I've never known where that address demosite.local came from.  To get around this, I just added this demosite.local as new entry in my hosts file on the RPi (/etc/hosts) and mapped it to 127.0.0.1 (= localhost).  That solved the issue and I wasn't thinking about the root cause anymore any further.

Until recently, when I started to use Laragon to create Wordpress websites.

Laragon has an option to auto-create virtual hosts.  One of the websites I created was (stupid name, I know...): blog.

What I didn't know was that, although Laragon warned me that it would do it, Laragon added an entry in the hosts file of Windows because of that auto option thing.

This hosts file is located in c:\Windows\System32\drivers\etc.

The modification looked like this:

c:\Windows\System32\drivers\etc>cat hosts
127.0.0.1     blog.test     #laragon magic! 

It writes it literally like this.

All of a sudden, I didn't see demosite.local anymore as address, but blog.test (the auto hosting creation in Laragon adds a default postfix .test to the virtual host).

Asking Copilot what this could be, the answer wasn't clear.  I got lots of (mostly misleading) suggestions, until I looked into that hosts file and saw the virtual host blog.test.

So, what happens is: when NetBeans wants to fill in the address parameter, it asks Windows for a host name.  Windows is looking into the hosts file and sees blog.test as host name, so it passes it on to NetBeans which uses it as the property for the address parameter.  Hence, I saw now blog.test instead of demosite.local.

I'm not sure anymore, but demosite.local must have been in that hosts file one way or another (or in another hosts file on Windows?).

So, I had still the problem of a failing debug session.  

There were 3 solutions:

• Add the newly created virtual host name again in the hosts file on the RPi
  Drawback: if I create a new Wordpress website with Laragon, Laragon might put the new virtual host on top of the hosts file and I will have yet another address parameter, when I start the remote NB debug session for that new project.
  So, I would have to add another entry in the RPi hosts file.

• Modify the file remote-platform-impl.xml and where there is the entry address=${jpda.address}, replace it with address=localhost:${jpda.port}.
  This should happen at 2 locations:  one area that is used when you connect to the RPi with the password flavour and one are that is used when you connect with the key flavour.
  Since localhost is always in the RPi hosts file, this will always work.
  Big drawback: if you create a new project in NetBeans, you have to do the same modification again, since that XML file is a per-project XML file.

• The best solution:
  Open a DOS command box and type hostname.  See what comes out of this.
  Open the Windows hosts file and add that hostname as first line like so (assuming the hostname is Win10):
  127.0.0.1 Win10
  Now, if Laragon continues to add new virtual hosts, it will add it after the standard Windows host name, since Windows takes this name as priority hostname when someone (here: NetBeans) asks for it.
  I've tested this and it works like that. 
  Prove:
  c:\Windows\System32\drivers\etc>cat hosts
  127.0.0.1      Win10
  127.0.0.1      bloggie.test         #laragon magic!
  127.0.0.1      ikkie.test           #laragon magic!
  Here, I added the first line myself, while Laragon added the next two lines, respecting the order.

If I now start a debug session, I nicely get 127.0.0.1 as address parameter, since Windows will see Win10 as hostname in the hosts file and return 127.0.0.1 as parameter.

Advantage: I don't have to change any file at all to accomplish this!

Yet another adaptation needed

Another issue I had was that I got this error too (see again this secion):

cmd : cd '/home/pi/mystuff/NetBeansProjects//Pi4J_V2_Test'; '/usr/lib/jvm/java-11-openjdk-armhf/bin/java' ${debug-args-line} -Xrunjdwp:transport=dt_socket,address=demosite.local:58571 -Dfile.encoding=UTF-8   -jar /home/pi/mystuff/NetBeansProjects//Pi4J_V2_Test/dist/Pi4J_V2_Test.jar

Error: Could not find or load main class args-line

Caused by: java.lang.ClassNotFoundException: args-line 

To solve this issue, I had to modify the build.xml file and add this line to the end of the file (just before the closing  </project> XML element:
    <!-- Necessary when debugging the code on the Rpi -->
    <property name="debug-args-line" value = ""/>

Note that this is not an issue when you're not running a debug session, but a release session.

Auto-copying the homecontrolsetting.json file

Since my application needs an input file called homecontrolsetting.json, this file should be copied to the RPi whenever the whole project is copied to the RPi.

To accomplish this, we have to modify again the build.xml file.  In the build process, there are several "sync" points where you can interfere and do extra things.  One of those trigger points is -post-jar (see the comments section in build.xml).

The following code block has to be added to the file (note that is is also a per-project file, so it has to be repeated for new projects!):

    <!-- Copy homecontrolsettings.json to the RPi on two different locations -->

    <target name="-post-jar">

        <property name="settings.file" value="homecontrolsettings.json"/>

        <property name="remote.base" value="/home/pi/NetBeansProjects/HomeControl_NB12.5"/>

        <property name="key.file" value="E:/AppData/Putty/PrivateKeys/Windows10_Private_Key_RSA_openssh"/>

        <!-- Split username and host -->

        <property name="ssh.user" value="pi"/>

        <property name="ssh.host" value="192.168.1.41"/>

        <!-- Ensure the base directory exists -->

        <sshexec host="${ssh.host}"

                 username="${ssh.user}"

                 keyfile="${key.file}"

                 trust="true"

                 command="mkdir -p ${remote.base}"/>

        <!-- Copy to main directory -->

        <scp file="${settings.file}"

             todir="${ssh.user}@${ssh.host}:${remote.base}"

             trust="true"

             keyfile="${key.file}"/>

        <!-- Copy to dist directory -->

        <scp file="${settings.file}"

             todir="${ssh.user}@${ssh.host}:${remote.base}/dist"

             trust="true"

             keyfile="${key.file}"/>

    </target>

First, a few "variables" are created which are used throughout the scripting (avoid repeating the same thing over and over again).  Next, there are two actions defined:

• one action to copy the file to the remote base directory

• one action to copy the file to the remote base .\dist directory

Both are needed, otherwise the app will crash in both debug session as well as in release session.

Since this has to be done "automagically", the OpenSSH private key file must be passed when executing the SSH command.

• Java .jar files are platform-agnostic.  Such files contain only byte code and does not depend on 32 or 64 bit.
  
  So, .jar files generated with a 64-bit JDK on Windows will perfectly work when used on a RPi running a 32-bit OS.