This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | The OSX disk image should hold only NetBeans.app, not an mpkg file | ||
---|---|---|---|
Product: | installer | Reporter: | emi <emi> |
Component: | Mac Native | Assignee: | Libor Fischmeistr <lfischmeistr> |
Status: | NEW --- | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | Mac OS X | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
emi
2009-09-30 22:46:06 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. 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. 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. "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. |