Definitely - I am sure that doc, or some version of it, used to be linked from the installation instructions.

cc'ing docs ppl - guys, can we add this ?

Well, it appears no one cc'ed has made the time to do anything about it...

On a related note, though this is more a feature request I'm not sure at all where to stick, one packaging option I'd
like to see is like the zip distro, i.e. no bundled runtimes, but with same installer as other packages in that it sets
up the Start Menu and uninstall entries, etc. The difference would be it would look for previously installed compatible
versions of those runtimes, offering to download and install, separately from the IDE tree using their own
install/uninstall system if they have one, only if not found. This would allow people doing updates to download just the
zip distro and unpack it over the tree, ideally, especially for the nightly test versions; without disturbing those
runtimes in matters like registry usage clashes or the wrong DLLs being found because of path order, and use runtime
releases even newer than the bundled ones as they become available. The ZipDistro FAQ would need to be updated to show
how those smaller bundles, aside from the obvious benefit of less download time required per update, could be more
desirable for them than the bundled installers. Me, I install all the runtimes from Sun to one directory tree, Apache
another, Php and Ruby to others, and so on, and don't need those runtimes duplicated under the IDE tree. They take up
enough space on the drive already......

If an update does depend on features of a newer runtime module than currently installed, the IDE can have a startup
routine incorporated that does a similar installation check and downloads and installs side-by-side with current version
of the runtime, where plausible like for the Java VMs, or updates it in place. The IDE/Installer could suggest default
install locations that coincide with those of the bundled installs, but it shouldn't require it, nor IMO should any
runtime compatibility plugin bundle be accepted for the Update Center that hard codes an install location, or sets up
default settings assuming only their bundled version was the only one you'd have on the system.

Just my 3 or 4 cents, from a users perspective :) and please route where appropriate,
Mark

Apologies for letting this fall through the cracks. Recategorizing to usersguide, where this will be tracked by the docs
team and will not be lost.

Irina, can you look at this?

Ty for the reply... The basic request is more a nitpick, so I'm not that surprised it fell through a crack, but it does
have extrapolations that aren't, as the Addendum begins to show, and I've more on below. Two things I forgot, still at
the nitpick level, is the Faq presently doesn't give much guidance on how to properly hook in the external runtimes they
don't bundle manually into the zip distro, where some screen shots of an installion showing properly done settings would
be nice, especially if you want to run it with a particular Java SDK or App Server when a user has more than one
installed for testing or backwards compatibility purposes; and what's with the separate Module Clusters downloads - what
caveats are needed for using them as updates. Also, beginning non-nitpick part, since you can unpack various versions of
the zip distros into separate directory instances, has much thought been given to per machine/per user/per version/per
instance settings handling, not just per machine/per user and per machine/per instance handling?

At present it seems each IDE version has their own pool of tested compatible plug-ins on the server that each instance
must install separately, i.e. per machine/instance, and the $HOME/.netbeans directories for per machine/user settings,
but I'd think with some effort it would be possible to have a pool of downloaded plugins that each instance could load
from, tailored to the preferences of each user, and duplicating base functionality for different versions only where the
versions aren't backwardly compatible. This would not be the same as workspaces or personalities of the IDE, in that
those still load extra plug-ins to make sure you can switch modes easily, once it's ALL loaded, but more for allowing
lean and mean customizations for specific tasks that limits Java VM system resource usage without unnecessary
duplication amongst the plug-in parts. You'd need separate areas in the pool for "IDE version specific" and "IDE version
or later compatible" plug-ins, but the net effect would be to reduce the amount of downloads required to be on the
machine, the space required to store the plug-ins on netbean's mirrors, and potentially much faster IDE load times and
peppier response once loaded.

Doubt you'd need to change the plug-in manager UI much either, mostly changing Installed Plug-ins view to be titled
Attached Plug-ins; adding a "locally available also" indicator in the Available Plug-ins view, with zero download time,
and noting the earliest IDE version the plug-in is compatible with; and an addition to uninstall confirmations whether
the plug-in should just be Detached or local files Deleted also if it's the last instance that was using the plug-in. In
the cases where a runtime was also bundled the option to leave it or uninstall that also using it's own mechanism, where
applicable, would be needed when the plug-in gets deleted. A corollary benefit could be that a plug-in written first for
version 5.5, e.g., might need only a much smaller add-on package to take advantage of version-specific aspects of
version 6.5, or later, and still operate with reduced capabilities if it was written to be later-compatible and those
features are all a user needs to have available. Even one that isn't later-compatible might need just an even smaller
add-on package to make the reduced features available in the later IDE version.

Lastly, as a corollary issue, possibly considerable as a bug with how some plug-ins are designed, if a plug-in requires
an add-on runtime that isn't installed on the machine yet, this should also IMO be indicated in the Available Plug-ins
view, and whether that runtime has a free usage license, or fee'd only usage license, or only the version bundled with
or installed via the plug-in is free, but may or may not work with separately installed fee'd version. As an example of
the latter, Trolltech's Qt has, for a given revision level, both free GPL-based versions and fee'd non-GPL versions with
extra features and support, and a plug-in supporting both could be written, if it hasn't already, for the C++
environment and bundled with the GPL-based version. The buggy part is some plug-ins may download and seem to install
fine, but when you try to load them they can hang or abort the entire IDE load because the runtime isn't installed and
the init routine can't setup defaults pulled from the settings for that runtime. It happened with one, at least, where I
installed a plug-in because I wanted to see some of what its feature set is, but had to go in and remove it manually
with text editor and file manager because the IDE wouldn't load far enough I could use the plug-in manager for that
instance to do it. I forget which one, exactly, because with nuisances like that, and a few others like it taking long
enough to load on my machine I can make a pot of coffee while waiting, I've been evaluating other IDEs also in the
meantime. Most still don't have the same breadth of possible features, but generally take under a minute to startup.

Please, if these ideas for a new variety of installer is made a seperate Work Item or Items, post here which Issue
number(s) are assigned so I can track them. Aside from the installer being modified, I see where aspects of the IDE and
platform design, plus plug-in authoring guidelines and interface might be touched by it; so it isn't necessarily
something trivial in scope and may have to wait until Version 7, or 8, but there's enough already there I don't think it
would require a major overhaul either. It's more taking what's there now in theory out to a more flexible in practice
next level, without sacrificing the simplicity for newcomers provided by the current installers. It's also, I think, a
more solid foundation for enterprise level, multiple machine, physical and virtual intranet and internet based,
installation management and usage, but I won't get into that here, as I'm not one of those enterprises large enough yet
to really benefit from it :) but; you could prefix the per's quartet of the first paragraph with "per internet
gateway(s)/ per virtual intranet/ per local intranet (building)/ per localnet (workgroup)/ per subnet (testbed)/"
settings and configuration management, and variations thereof.

TIA,
Mark

Appears it has been lost again... Bumping priority, target and status so maybe it gets more general attention, since no
one has said it shouldn't get done. Perhaps another person should be assigned, or volunteer to take it on, as I've no
idea what Irina's workload is.

Happy Holidays,
Mark

Mark - there's a lot here, probably it should be split off into seperate feature requests.  Let's keep this issue
focussed on the original request - the install page should describe how to install the zip distribution.

Patrick, Irina - can you pls look at this ?  There is no mention of the zip distro on the 6.5 install page.

Yes, I'm not expecting more than the doc update.

I did put 'route where appropriate' for the rest, as it's more philosophical
on whether the platform is feature complete by design rather than accident,
and I've no idea which person or people might be in charge of this that I'd
have an idea who to address specific feature requests to.

Happy Holidays,
Mark

The latest installation instructions for 6.5.1 have been modified to include information about using/uninstalling the OS
independent package -- http://www.netbeans.org/community/releases/65/1/install.html

Regarding the enhancement proposals contain in the issue description, I recreated it as an enhancement and assigned to
the appropriate engineer, Dmitry Lipin.

Well, it's an improvement... However, just saying 'they're not bundled' doesn't address how to get the unbundled
versions and note what paths are needed, parametrically, to hook them into the IDE, and, are there additional pkug-ins
that need to be downloaded from the plug-ins site to give those paths their proper home. Without this info you may as
well say the zip distros are only for J2SE, C++ and PHP development, since those expect the unbundled runtimes anyways.

There's also no mention of the split apart packages in the sub-dir off where the ZIP bundles are located; how someone
might install them, say on top of a test platform compile out of the repository.

Thanks,
Mark

Hello Irina,

Could you please correct "Platform-Independent Package" section in
http://www.netbeans.org/community/releases/65/1/install.html#install_zip

The User should perform some configuration before running the executable file.
The variable "netbeans_jdkhome" in the etc/netbeans.config should be set to point to the compatible JDK installation to
use with the NetBeans IDE.

Thanks,
Yulia

Ups, sorry, a little correction:

netbeans.config -> netbeans.conf
should -> may

So, please, read preceding comment as:

The User MAY perform some configuration before running the executable file.
The variable "netbeans_jdkhome" in the etc/netbeans.CONF MAY be set to point to the compatible JDK installation to
use with the NetBeans IDE.

I added the information about modifying the variable "netbeans_jdkhome" in the etc/netbeans.conf file - for the
Platform-independent bundle.
http://www.netbeans.org/community/releases/65/1/install.html#install_zip

Hi Mark,

Answering to your comments about more information needed on the installation options for the ZIP download. 
I opened a new issue - http://www.netbeans.org/issues/show_bug.cgi?id=162557 - to keep track of the documentation task. 

The current issue has been reassigned to engineers to evaluate your proposals regarding additional functionality. 

Assigned to new owner.