Bug 173435 - The OSX disk image should hold only NetBeans.app, not an mpkg file
The OSX disk image should hold only NetBeans.app, not an mpkg file
Status: NEW
Product: installer
Classification: Unclassified
Component: Mac Native
6.x
All Mac OS X
: P3 (vote)
: TBD
Assigned To: Libor Fischmeistr
issues@installer
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-30 22:46 UTC by emi
Modified: 2014-02-10 14:15 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description emi 2009-09-30 22:46:06 UTC
I don't see the need on OSX for the .mpkg (installer file). You can have a license with normal .dmgs that hold
applications too.

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.
Comment 1 _ tboudreau 2009-09-30 23:52:25 UTC
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 
classloading does.
Comment 2 emi 2009-10-01 07:51:09 UTC
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
representative.
Comment 3 dlipin 2009-11-04 13:39:28 UTC
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 
for that.
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.
Comment 4 kwerle 2009-12-02 13:51:06 UTC
"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.
Comment 5 dlipin 2009-12-04 06:35:41 UTC
Right, we don`t have it now, see Issue 115779
Comment 6 Jiri Rechtacek 2012-10-07 12:58:26 UTC
Assigned to new owner.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo