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.
This issue was reported manually by epdv. It already has 5 duplicates Build: NetBeans IDE Dev (Build nbms-and-javadoc-7540-on-20110716) VM: Java HotSpot(TM) Client VM, 11.0-b16, Java(TM) SE Runtime Environment, 1.6.0_11-b03 OS: Windows XP User Comments: epdv: 1. Updated NB 2. Module com.jcraft.jsch missing 3. Resolving broken module dependencies Stacktrace: java.lang.NullPointerException at org.netbeans.modules.moduleresolver.ui.LicensePanel.writeLicenses(LicensePanel.java:228) at org.netbeans.modules.moduleresolver.ui.LicensePanel.setElements(LicensePanel.java:90) at org.netbeans.modules.moduleresolver.ui.LicenseStep.readSettings(LicenseStep.java:107) at org.netbeans.modules.moduleresolver.ui.LicenseStep.readSettings(LicenseStep.java:56) at org.openide.WizardDescriptor.updateStateOpen(WizardDescriptor.java:910) at org.openide.WizardDescriptor.updateState(WizardDescriptor.java:861)
Created attachment 110144 [details] stacktrace
Created attachment 110149 [details] stacktrace
Created attachment 110150 [details] stacktrace
This bug already has 10 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=29325
I cannot update "X.509 Certificate Support", too. Seems to be related, as it uses two external libraries: - org.apache.commons.codec - org.apache.commons.lang Probably this is the problem: Upgrading modules containing external libraries.
Belongs to contrib/moduleresolver, it's not a part of standard IDE distribution. I'm going to fix it to NB7.1-beta, anyway.
Autoupdate doesn't work either, though not throwing an exception: Autoupdate wants to update X.509 Certificate Support with the following modules: org.apache.commons.codec [1.0 -> 1.3.0] org.apache.commons.lang [1.0 -> 2.4.0] This doesn't work: AU always again wants to update these modules after restart, the same modules are found be resolving missing modules, throwing the exception, so there seems to be some common problem with the update.
I've had a look at the Module Resolver, there seem to exist two problems: one about the license (which is resolver-specific) and one about (not) installing (related to autoupdate). Let's solve the first one first, there's just no HashMap created when there's no license found. So it's probably sufficient to surround the for-loop with if (license4plugins != null) { for ... { ... } }
I've tried to find out more, and it seems, the required modules are not available, in fact. Well, I've tried to build the module c.jcraft.jsch, and I've not been able to create the nbm file (while it has been possible for other modules which I tried). The above mentioned module was always missing, too, so I've once copied the platform cluster from a zip file. Now it looks like this: - The modules build file seems to have problems, so only jar file is build, nbm target is executed but probably sth. is missing, so nbm isn't build. - As some module requires the corrupted one, MMR tries to load it, but as it cannot find the nbm, no license is found, resulting in a non-existant license container (which rises the NPE). - This seems also to be the cause for never updating though needed updates are found (obviouly the update.xml is generated correctly).
Some additional infos: - All three non-updating "modules" are in fact jar files containing libraries. - Two of the jar files contain a license. - The jar files are found on UC, but obviously only nbms are considered for update after restart.
Forgot to mention: All three modules are part of NB sources, i.e. part of the standard distribution, so update should really just work.
NPE fixed in http://hg.netbeans.org/main/contrib/rev/a523c3ca2f5d, the problem with updating libraries has been fixed in http://hg.netbeans.org/core-main/rev/c74fddc50562. If not, file a separate bug. Thank you
(In reply to comment #12) > NPE fixed in http://hg.netbeans.org/main/contrib/rev/a523c3ca2f5d, the problem > with updating libraries has been fixed in > http://hg.netbeans.org/core-main/rev/c74fddc50562. If not, file a separate bug. > Thank you If I understand correctly, the c74fddc50562 has been integrated a week ago in autoupdate.services. Did You ever change the spec version since then? However, it does not seem to be sufficient, still cannot update some internal apache libraries, though re-installed autoupdate.services from a local build (previously fetched from hg.netbeans.org). Can I try anything else to get it working? Otherwise I'll file a new bug this evening.
(In reply to comment #7) > Autoupdate doesn't work either, though not throwing an exception: > > Autoupdate wants to update X.509 Certificate Support > with the following modules: > org.apache.commons.codec [1.0 -> 1.3.0] > org.apache.commons.lang [1.0 -> 2.4.0] > > This doesn't work: AU always again wants to update these modules after restart, > the same modules are found be resolving missing modules, throwing the > exception, so there seems to be some common problem with the update. X.509 Certificate Support comes with some thirdparty modules which have the code name base org.apache.commons.xxx. those were installed in your userdir, but in the meantime there were new modules introduced to the ide cluster with the same code name base-s. the problems you got seem to be caused by a clash between the modules in userdir and those in the nb install dir. try to run a current build with the userdir stripped from the trhirdparty modules, or ideally, with a new userdir. - 1.0 is the version for the module in userdir - 1.3.0 is the new modules version where exactly speaking o.a.c.codec 1.3.0 isn't a newer version of o.a.c.codec 1.0 autoupdate should be smarter about such a scenario but this seems to be a different issue than the one originally reported
Filed a new bug #202161 about wrong behaviour of updates when module locateion changes.