I don't see the need on OSX for the .mpkg (installer file). You can have a license with normal .dmgs that hold
Furthermore, the current installer is very restrictive as it expects to install the application on a particular path and
generally requires administrator rights.
A normal .dmg with the NetBeans.app should allow any users to drag-and-drop the application in whichever folder they prefer.
We've actually been back and forth on this over the years. Here are the pros and cons and the reasoning behind the way NB is packaged on Mac OS:
MPKG: NetBeans ships on all other platforms with a Java-based installer, which lets the user choose if they really want to install everything (for example, if
you already have Glassfish, you probably don't want another copy). We chose to use MPKGs because they offer the same flexibility for Mac OS users (while
providing the native installer experience, rather than an obviously non-native installer) - you can choose what things you actually want to install. If we
used a single-package installer, Mac users would be complaining that they were forced to install everything, while users on all other OS's get a choice.
In the past we did use a single-package installer - some early documentation of my experiments to get it working from Ant can be found here - http://contrib.netbeans.org/osx-native-installer/
DMG: We did ship an (unofficial) DMG for NetBeans 3.5. If you looked on the Apple Java Dev mailing list at that time, you would see a lot of complaints
that NetBeans was terribly, terribly slow. The reason: A .dmg file is a *compressed* disk image. Java applications load classes from JARs - this means a lot
of random-access reads from various spots in files inside the application. The reason people were complaining was because it *was* deathly slow - *if*
you ran it from the DMG instead of copying the application out onto the hard-drive somewhere, the time to load every single class was massively increased
because the data had to be decompressed by the OS for it to be read. If we offered a DMG of NetBeans, a lot of people would run it directly from the DMG
and have a really, really bad experience. A native application which is read into memory on startup probably won't have this problem; Java's dynamic
Ok, maybe for some types of packages it makes sense to use the installer. But personally I just download the JavaSE dmg
and then, if needed (but not really) I can always use the update center to add J2EE or whatever.
And the JavaSE installer really doesn't have any significant dialogs except the license agreement, which could be done
without the MPKG.
The DMG issue of users trying to run NetBeans from the dmg alone could be easily fixed by checking some hidden file in
the DMG (just a marker, like .inside_dmg) and displaying some dialog to the user that it won't run from the DMG directly
and it needs to be copied.
I'd estimate that the total annoyance of people going through the installer (and not having a configurable target
folder) is way greater than the annoyance of people that don't know any better than execute the app from the DMG
directly. Of course, the 2nd bunch is probably the most *vocal* about it and thus makes you believe they might be
There are a few things that come to mind if answering the question "why not .app?":
1) We use pack200 to pack the installation data which saves us about 50% of download size.
We unpack the files during installation and that takes a few minutes depending on the distribution used.
To overcome this issue, we can probably do the unpacking during the first IDE start providing the UI with progress bar
2) We provide server integration for GlassFish and Tomcat which requires, at this moment, a system property been set in
etc/netbeans.conf to point particular server absolute location. In case of .app that is not possible since we can use
only relative location and put server bits inside the .app.
Possible solution could be, probably, using the same registration mechanism as with WTK/JavaME/JavaFX SDK (using XML
file) or something like that.
3) GlassFish 2.1(.1) can`t be just copied to another directory since it requires absolute paths been set in its
configuration files. No idea how to overcome that. Not a case for v3 and tomcat.
There are a few other minor but still important things (like productid file content, service tags) but they probably
can be solved by proper packaging.
To the end, like Tim said, the customization feature is also an important point of the mpkg/app choice.
"To the end, like Tim said, the customization feature is also an important point
of the mpkg/app choice."
The only customization I want to do is say where to install it. mpkg does not let me do that.
Right, we don`t have it now, see Issue 115779
Assigned to new owner.