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.
[Nb Build 200207252340, jdk1.4.0_01] Installer doesn't import folders like {$userdir}/modules, lib, etc. from 3.3.2 userdir (in contrast to Setting Import Wizard). It is problem of all 3.3.2 XML users because XML wasn't in standard 3.3.2 distribution and is available via AutoUpdate. Steps to reproduce: ------------------- 1) run 3.3.2 with empty userdir 2) install all XML modules via Update Center 3) exit 3.3.2 4) run Nb 3.4 installer 5) slelect Import Settings from: NetBeans IDE v3.3.x 6) finish instalation IDE starts and displays 18 Warnind Dialogs and a lot of exceptions (see ide.log) and it will happen at every start. Workaround: ----------- Remove .xml files from {$Nb3.4-userdir}/system/Modules folder.
Created attachment 6917 [details] ide.log
Hi, these issues block the 3.4 release. It has been suggested on nbdev that those that are not going to be fixed for 3.4 FCS (waivers) change the target milestone to "future" or "4.0". I'd like to suggest you to do so, if you and your reporter agree on that.
If this bug is not fixed then it should be documented in release notes.
"3.4_WAIVER" keyword
I am not sure I agree with the waiver, it seems odd that the import process in the installer behaves differently than the one in the ISW. One the other hand the number of users affected by this seems to be rather small, so if sufficient explanation to why the import settings in installer behaves differently than in ISW can begiven, I'll be fine with waiving it.
I'm not clear on what the workaround accomplishes. What are the .xml files that the user is supposed to delete? Is the user able to run with all of the 3.4 functionality if those XML files are deleted? Also, no comment was made about the difficulty of fixing the bug.
Afected are users who have in Nb 3.3.2 some module installed via autoupdate. For example 3.3.2 XML module have about 25000 downloads. And all of them will get Unexpected Exception and in case of XML 18 Warning Dialogs during every start. In the {$Nb3.4-userdir}/system/Modules folder are module status XMLs for modules from missing {$userdir}/modules folder. So user is able to run with all of the 3.4 functionality if those XML files are deleted.
I don't agree with the waiver. This is clearly a pretty user-visible problem; has been reported at least once on nbusers too. Updating XML modules in 3.3.2 is not unusual at all, and it will leave a bad impression of 3.4 if it shows numerous exception dialogs while importing a 3.3.2 user dir. 1. I cannot actually reproduce the reported problem, because the Linux installer for 3.4 RC1 did not prompt me to import 3.3.2 settings! Not sure what I am doing wrong. Using the upgrade wizard when actually starting 3.4 seemed to work as expected. 2. The installer is clearly at fault if it in fact does not carry over the old $userdir/modules/ yet does not correspondingly fix up $userdir/system/Modules/*.xml, by deleting the XML file describing any module JAR it is also deleting. 3. However, issue #26151 reports that the module system does not handle this installer error as gracefully as it should. QA: please try the patch attached to that issue and confirm that it behaves as described. Summary: there is an installer bug, but an improvement in robustness and error reporting UI in the module system may be a more appropriate quick fix for 3.4. Opinions requested.
Clarification re. missing functionality and so on: there are two cases to consider. 1. (Reported here) The old userdir had some modules from AU which are now in the standard distro. Or, it had some updates of standard modules from AU. When the old userdir's modules/ dir is deleted, it does not really matter, because the new 3.4 installation's modules/ dir already has newer versions of these modules anyway. However the XML files are carried over and still claim that the modules live in the userdir, when really they don't. With the #26151 patch, the XML files should be deleted on first 3.4 start with a small warning; on the second start (or later during the first start, perhaps - TBD) they should be recreated, with <param name="origin">installation</param> rather than the old <param name="origin">user</param> (ditto installation/autoload vs. user/autoload etc.). The only practical drawback is that if some of these modules had been explicitly disabled before, they will now be quietly reenabled. That is a consequence of the installer and/or upgrade wizard deciding to not carry over old module JARs intact into the new $userdir/modules/ - which I don't consider a bug if the XML files are updated or deleted to match, though this behavior might be reviewed for the future since some users have complained about it. 2. (Not reported here, and needs to be tested as well) The old userdir had some experimental or third-party module not in the new distro. The JAR is deleted by the installer. With the patch, the XML file will be deleted during 3.4 startup with only a console warning. There should be no remaining trace of the module. The user might decide to go back to AU and get the module again, or a newer version of it, etc.
I remove "3.4_WAIVER" keyword because missing justification.
*** Issue 26189 has been marked as a duplicate of this issue. ***
*** Issue 26225 has been marked as a duplicate of this issue. ***
*** Issue 26247 has been marked as a duplicate of this issue. ***
it's important to realize that once the user used the faulty installer to install the IDE, his userdir is corrupted forever. RC uses {user.home}/.netbeans/3.4 as the default userdir, the same as 3.4 FCS. This means - either the FCS installer must detect the corruption and fix it (non-trivial task I believe) - or we must document the way to manually fix the userdir somewhere (at the beginning at the release notes perhaps)
Note that merging issue #26151 would (I believe) quietly repair the corruption without any help from the installer.
Question: Does the user have to go back to the update center to load the XML modules? Or just modules that are not in the 3.4 distro? Proposed release note (please correct any inaccuracies): Description: If, when you are installing the NetBeans 3.4 software, you choose to import settings from a previous version of the IDE, modules that you added to your previous version of the IDE through the Update Center will not be imported. Workaround: Use the Update Center to reinstall those modules.
XML module is part of standard distribution now therefore useres do not havet to go to the update center to load the XML modules. But other modules have to be reinstalled. Proposed release note is correct.
"3.4_WAIVER" keyword. There is workaround (issue #26151). It will be implemented in the future.
Problem is that there isn't started ISW at all. It should be run in none-interactive mode without GUI - but should be run.
Installer creates upgrade.properties file for ISW. Existence of this file makes ISW start in none-interactive mode.Should be fixed from installer point of view.
If this is really fixed in 4.0, please set the target milestone properly.
Hi. This issue is marked as 3.4.1_CANDIDATE. It means that it should be integrated into release341 one branch. The plan at http://www.netbeans.org/devhome/docs/releases/34/index.html expected beta1 to be produced on Dec01. That did not happen due to a lot of outstanding not integrated candidates like this one. Would it be possible to spend few minutes by backporting this fix? Thank you in advance.
Issue bacported.
any commit logs?
cvs di -r release34 -r release341 installer shows a bunch of changes, I don't know what they mean though...
There are changes concerning this issue.Mainly changes in WriteAction and DetectAction. They are responsible for detect previous version and setup files for IDE to run Import Settings Wizard in noneGUI mode.Those changes are in trunk and they were made after 3.4 release and are important for correct import.
http://www.netbeans.org/issues/show_bug.cgi?id=26049
what I meant to say was "removing RELNOTE keyword as this does not seem to apply to 3.5"
VERIFIED