Provide installers for Apache NetBeans releases for Windows, Linux, and Mac OSX

Plan A

In the ideal world, we'd simply use the same source code as was always used, in the Sun days, in the Oracle days, etc, to create installers.

Problem 1: The installers we used to have always bundled the JDK, which we cannot do under Apache, since the JDK is GPL licensed, hence we cannot distribute it from Apache as an Apache NetBeans installer.

Problem 2: Even if we don't bundle the JDK, and let the user specify the JDK to be used during installation, we still need to bundle the JRE with the installer, in order for it to run, since it is written in Java. The JRE is also GPL licensed, hence this cannot be done.

Hence, even though Oracle has donated the sources for creating installers (https://github.com/apache/incubator-netbeans/pull/1052), we cannot make those installers available from Apache.

Potentially, Oracle or Amazon or any other vendor could use the sources from the PR above to create installers for NetBeans and bundle it with their JDK, though licensing questions relating to the naming of Apache NetBeans, i.e., the name is licensed to Apache, could apply.

Plan B

Given that we cannot bundle the JRE and/or the JDK, we need a non-Java approach to create installers, and they cannot be created in a standardized way, instead for each operating system different requirements and procedures apply. A minimalistic non-java part of the installer could prompt the user to first install JDK.

Windows

I would like to share the script with you to create the installers.
Please find the attached ISS script in this email.
You can open it using Notepad or any other text editor app of your choice.
This script will create a 32-bit installer. Though you can also tweak the
script to create a 64-bit installer. (Some of the paths point
to my computer, please change that according to yours.)

https://lists.apache.org/thread.html/873595d1682e6aac4c58e69748dbe8b5e8530d36bda4e66256173203@%3Cdev.netbeans.apache.org%3E

Action Items:

  • The above referenced script needs to be donated to Apache NetBeans.
  • Someone in Apache NetBeans needs to use the script to create the installer, via Inno (jrsoftware.org/isinfo.php).
  • Maybe this can be automated during the build?
  • The installer needs to be made available on the Apache NetBeans download page.

Mac OSX

This debate was had once about 14 years ago - and the decision to go with
.pkg installers on Mac OSX was made for this reason: There were a lot of
"NetBeans is unusably slow" reports on OSX.

The reason? A LOT of users never unpacked the .app - they were running it
directly from the mounted, compressed .dmg image. It turns out that's not
that unusual.

Random access Java classloading does not play nicely AT ALL with the
compression used for .dmg images.

I strongly recommend not repeating that mistake.

https://lists.apache.org/thread.html/ec164d9dcab6e9caeeceded6fc085afa3729ed8dc597fee6d49d9c8c@%3Cdev.netbeans.apache.org%3E

http://www.owsiak.org/netbeans-make-macos-installer-beautiful-again/

https://github.com/carljmosca/netbeans-macos-bundle

you can make any executable file an
Application just by moving example.sh to
example.sh.app/Contents/MacOS/example.sh. You can place the Application in
your dock like any other, and execute it with a click.

https://lists.apache.org/thread.html/fbf4e7ec019e457a59fafed878f10ac33b97caa9afb98b21d0dd15fc@%3Cdev.netbeans.apache.org%3E

Action items:

  • Though the above various approaches are useful, we need to have some kind of package, whether DMG or whatever, available on the download page.

Linux

https://snapcraft.io/netbeans

  • The above is created by Apache NetBeans infrastructure by the: incubator-netbeans-snap-release job, hence can be called Apache NetBeans, and be stated as such on the Apache NetBeans download page, i.e., this is an official Apache NetBeans distribution.
  • How complete is the above solution, does it work for all Linuxes, what's better/worse about appimage.org?
  • With the historical NetBeans installers NetBeans IDE was installed in /usr/share/ path. With the policy of many Linux distributions this location is reserved for package management controlled programs, so the /opt/ path should be used instead. A prompt for manual change of the install path could be nice.
  • No labels