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.
Tested installers: netbeans-trunk-nightly-201009060000-windows.exe (o.k.) netbeans-trunk-nightly-201009090000-windows.exe (corrupt) netbeans-trunk-nightly-201009100000-windows.exe (corrupt) Seems, NB is trying to install sth., then breaks. Next time tries to delete sth., breaks. First time, splashscreen pops up, further tries not. Using non-empty .netbeans\dev folder. Seems like some fix for re-writing some files tries to first delete some files and the re-install them, probably license files. Probably breaks because of access rights, though logged in as admin (probably the files to be removed are write protected?). Sorry, no more time to further investigate, today.
Could you please attach a installer log file (.nbi\log)? I can't reproduce the issue on my Windows XP.
Created attachment 102022 [details] nbi log removed all the log from .nbi before installing from netbeans-trunk-nightly-201009130000-windows.exe
Created attachment 102023 [details] First log after install Removed log files before starting.
Looks like NB wants to delete the whole configuration / NB home. As an OSGi container, NB should *never* remove any configs.
NB can only be run after manual removal of NB dev home / configs. Especially for an OSGi container, this is not acceptable, IMO. Trying to remove NB home automatically hurts, as most parts of IDE don't work after an update (using many modules from several update centers). After upgrade, the whole window appearance is corrupted (i.e. not as I've arranged it), and many other config options are reset, so I've to re-configure NB about half a day! As message log says, this all is probably just about some licensing class ... shouldn't happen.
Peter, thanks for the information. According to the log It looks similar to http://netbeans.org/bugzilla/show_bug.cgi?id=189656 "WARNING [org.netbeans.core.startup.Main]: Failed to delete C:\Dokumente und Einstellungen\pna\.netbeans\dev" Another strange thing is that Installation = C:\Programme\NetBeans Dev 201009060000\xml C:\Programme\NetBeans Dev 201009060000\webcommon C:\Programme\NetBeans Dev 201009130000\platform looks like a mix of two different installations. Investigating.
Strange thing, indeed. Seems, NetBeans Dev 201009060000 did not uninstall correctly (as those clusters are not removed). Would it be possible to throw an AssertionError and report this to NB? I'd guess this to be difficult, but not impossible. Module owners would get a message then, and quality would probably improve shortly. Seems, the outdated modules are not removed from config, so new configs are not installed to point to the correct/new installation, which results in errors. However, just trying to remove NB home without comment is bad - at least the user should be asked, like in the case of missing modules: remove or exit?
Deletion of the NB dev home happens as a result of the fix for http://netbeans.org/bugzilla/show_bug.cgi?id=145936 Please discuss it with Jesse Glick. Reassigning.
Just because it might be forgotten: In my case, the deletion of NB dev home here is not a result of declining the license, but it's the result of an installation problem. BTW, in case of deniying the license, the user should at least be warned before deletion. However, in my case the bug is about wrong pointers because of incomplete uninstallation. Just the result is the same, because NB has a problem with "java.lang.NoClassDefFoundError: org.netbeans.license.AcceptLicense" and only *thinks* the license has been denied.
After re-thinking about the issue, the bug is *not* that the IDE cannot be restarted, but build 201009060000 does not uninstall correctly. The uninstaller needs to check for an empty installation directory (in my case C:\Programme\NetBeans Dev 201009060000). If not empty, this also means that some of the configs will be corrupted. So, if the installation dir is not empty after uninstall, the uninstaller *must* provide a dialog to allow sending an exception report. DO NOT delete NB dev home, please! Re-configuring IDE is just too much work! As long as there's no such exception reporter in the uninstaller, I'll file a bug against the not cleanly uninstalling build, as a workaround. As it will lead to unexpected crashes after upgrade (as is the case for this bug), I'll file the issue with P2.
About incomplete uninstallation: it looks like you installed NB 201009060000, then installed some additional modules from Update Center, then uninstalled 201009060000 version. Uninstaller couldn't remove the additional modules you installed from UC but It suggested to remove the userdir. You didn't accept. So you have problems with running another dev version of NB. You can find more info in an enchancement about Installer and AutoUpdate integration: http://netbeans.org/bugzilla/show_bug.cgi?id=54182
Hm, that's a five years old issue - will it ever be fixed? The problem is: It's only an enhancement request, but it fixes a serious problem with upgrading. Added a comment.
I'm sorry but I did not follow any of the preceding discussion. It is not even clear whether you are looking at a problem in the regular module system, OSGi support, or the installer. Please provide a way to reproduce whatever problem you are seeing - complete and clear instructions - so I can evaluate.
There are different views of the issue to keep in mind: 1. The result view: IDE cannot be started after upgrade. 2. The log: It tells about a licensing problem - which isn't the case. Seems some problem during startup leads to an error, which is re-thrown as a license exception. see second attachment 3. Module system: Seems to have problem with an incorrect parametrized module config. As NB now is an OSGi container, it should not run into such serious problems. Probably OSGi implementation could be improved. However, OSGi is not the source of the problem, it is just not able to handle some problems. 4. External modules: Some of them point to the outdated installation dir. Probably this causes what can be seen in the log /2/, as the outdated modules cannot use the upgraded classes. Probably the modules should handle their properties in a better way (e.g. use variables instead of hard-coded strings for NB installation folder). However, it will be hard to enforce all module developers to do so, thus user experiance will stay bad. :-( The only chance to get rid of such annoying problems seems to be implementation of ENH. 54182: Uninstaller gets a list of additionally installed modules and removes them, too. However, don't know what will happen to the modules' config then. Also, every module jar looked up in the non-current NB inst dir should be notified to the user (like other non-working modules dependent on outdated module versions) and the module should be de-activated. Another chance will probably be to implement easy-to-use utility functions to create symbolic paths (i.e. paths using variables) for writing into property files and getting them back as FileObjects. This would probably increase developers' readiness to implement their modules in a more stable way. HTH Peter
see also http://netbeans.org/bugzilla/show_bug.cgi?id=190384 for an example
I still see no steps to reproduce. Sounds like an installer issue but cannot really be sure.
You should have seen from the other bug reportrs I've referred to. However, just install a module which uses a cluster from NB inst dir like soa or xml, e.g. jbi4corba (soa), XML pack seems to install in xml cluster. Uninstall NB dev and install a newer build. In the message log You'll see some pointers to the old inst dir, while NB start crashes.
I don't think the installer was ever really meant for updating one dev build to another on a regular basis. Better to just replace your install directory with a new version from ZIP distribution and not touch your dev home directory at all. Then everything should work and you won't have to needlessly install new versions of things like GlassFish. (Of course, when heavily using dev builds sooner or later your dev home directory will get confused and you'll have to wipe it clean, really no way around that).
Until 54182 is implemented you should clean your userdir in case if you installed modules via UC. There is a check box in uninstaller that suggests you to do it. So this is a duplicate from installers point of view. Anyway I still can't reproduce the crash, NetBeans runs and works after upgrade even if userdir is not cleaned. I will play with it a bit more later. *** This bug has been marked as a duplicate of bug 54182 ***