There have been a few threads discussing how to build and deploy fixes to native binaries used by NetBeans. I’ve attempted to identify the native binaries in the NetBeans repo.
• https://github.com/apache/netbeans/tree/master/nbi/engine/native • https://github.com/apache/netbeans/tree/master/nb/ide.launcher/macosx • https://github.com/apache/netbeans/tree/master/harness/apisupport.harness/macosx-launcher-src • https://github.com/apache/netbeans/tree/master/profiler/lib.profiler/native • https://github.com/apache/netbeans/tree/master/ide/extbrowser/native • https://github.com/apache/netbeans/tree/master/ide/dlight.nativeexecution/tools • https://github.com/apache/netbeans/tree/master/java/performance/jtrace • https://github.com/apache/netbeans/tree/master/contrib/cordova.platforms.ios/iDeviceNativeBinding The problem is that fixing a bug or adding a feature to native binaries is a multi-step process. 1. Merge Pull request that fixes the native source code. 2. Get the native source compiled. For most of the native binaries there is no build automation for this. a. Lars has leveraged GitHub actions to get the lib.profiler native code compiled. b. Eric has moved the Windows native launchers to a separate repo. These get compiled on Apache Jenkins servers, is this correct? 3. The native binaries then need to be manually uploaded to OSUOSL by a PMC member. a. In the case of the Window native launcher, these get published to maven central. 4. Merge Pull request that updated the external/binaries list. 5. For the harness native binaries it is beneficial that nbm-maven-harness and nbm-maven-plugin get updated with new binaries. Lars might need to correct me on this. There are fixes for NBI native binaries which have been sitting in Git for long time but never made it into an actual release. PR #1844 fix for [NETBEANS-2523] and PR #1504 fix for [NETBEANS-3094]. So these fixes only got to Step 1. What can be done to improve this process of getting fixes/features in the native code into a binary that is included in a NetBeans release? Some ideas raised in other threads: 1. Use GitHub actions to build the binaries? This currently seems to be the only way to get a macOS binary compiled since Apache Infra does not have any Macs. (Except the macOS native launcher which gets compiled when John builds the Mac installer). 2. Move the native source into separate repos as Eric did with the Windows launchers? 3. Migrate away from storing the binary artifacts on OSUOSL in favor of maven central? 4. Other ideas? Here are various list threads related to this topic (in no particular order): • Profiling on 64bit Windows https://lists.apache.org/thread/388wddtwfjzxjs2xgkglh60ttnm05hy9 • Re: Profiling on 64bit Windows https://lists.apache.org/thread/lw1kw3jzo795lsh8vvs986wzgw93gtdt • Re: Profiling on 64bit Windows https://lists.apache.org/thread/rlso38wtpy34ykdlcngo1fcrtc2thb7n • GitHub Packages https://lists.apache.org/thread/bz82m710flcr8hsn85k26llj8ozz2n7r • How does NBI native binaries become part of a release? https://lists.apache.org/thread/rhnjo65lc4ojqhfsdyxsfnvlw1f19ljh • Re: Profiler crash on Windows (was: [NOTICE] Last PRs for Apache NetBeans 12.4 Beta) https://lists.apache.org/thread/21h2w0jv5rsmf59vrxpp2wpj6dfwjvrl • Native launchers repository https://lists.apache.org/thread/jggow0voyl1t1skd2d1owjppj1frkkpm • Re: Compiling shared libraries (cnd.remote) https://lists.apache.org/thread/4yfno0yyn3jy331l448ptl6cckb7q3ky --Christian
