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.

Bug 169529 - AssertionError at org.netbeans.modules.apisupport.project.ui.customizer.SingleModuleProperties.refresh
Summary: AssertionError at org.netbeans.modules.apisupport.project.ui.customizer.Singl...
Status: RESOLVED FIXED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: rmichalsky
URL: http://statistics.netbeans.org/except...
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-30 08:44 UTC by sreimers
Modified: 2009-08-08 07:03 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter: 154553


Attachments
stacktrace (3.55 KB, text/plain)
2009-07-30 08:44 UTC, sreimers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sreimers 2009-07-30 08:44:52 UTC
This issue was originally marked as duplicate of issue 160604, that is already resolved. This issue is still valid, so this seems to be another issue, but it might be related.

Build: NetBeans IDE Dev (Build 200907270201)
VM: Java HotSpot(TM) Client VM, 14.0-b16, Java(TM) SE Runtime Environment, 1.6.0_14-b08
OS: Windows XP, 5.1, x86

User Comments:
aldobrucale: Opening properties window for a just-renamed module project

sreimers: opening module project properties

tirau: This error occurred while trying to open a NetBeans RCP module project.

tboudreau: Right clicked a module after adding it to a suite

vieiro: Copying a project from one suite (with cp -R) and then adding it to another suite



Stacktrace: 
java.lang.AssertionError
        at org.netbeans.modules.apisupport.project.ui.customizer.SingleModuleProperties.refresh(SingleModuleProperties.java:225)
        at org.netbeans.modules.apisupport.project.ui.customizer.SingleModuleProperties.<init>(SingleModuleProperties.java:208)
        at org.netbeans.modules.apisupport.project.ui.customizer.CustomizerProviderImpl.prepareData(CustomizerProviderImpl.java:98)
        at org.netbeans.modules.apisupport.project.ui.customizer.BasicCustomizer.showCustomizer(BasicCustomizer.java:124)
        at org.netbeans.modules.apisupport.project.ui.customizer.CustomizerProviderImpl.showCustomizer(CustomizerProviderImpl.java:61)
        at org.netbeans.modules.apisupport.project.ui.customizer.BasicCustomizer.showCustomizer(BasicCustomizer.java:116)
Comment 1 sreimers 2009-07-30 08:44:57 UTC
Created attachment 85508 [details]
stacktrace
Comment 2 rmichalsky 2009-07-30 11:41:57 UTC
Cannot reproduce. Does it happen consistently on some project? Could you by chance attach some sample project on which
it happens regularly?
Comment 3 sreimers 2009-07-30 12:24:44 UTC
I think it may have been caused by a module beloging to a suite project, which did not exist on my filesystem (path to
suite in properties pointed to invalid not existing directory)

Having fixed this everything works as expected now - cannot reproduce this anymore
Comment 4 rmichalsky 2009-07-31 10:53:19 UTC
It has to be some combination of factors, just having suite.dir pointing to nonexistent platform is not enough, I tried
and IDE just warns about missing platform (and of course the project is not buildable). Closing, please reopen if you
the problem shows up again.
Comment 5 Jesse Glick 2009-07-31 16:18:35 UTC
As a rule, AEs should not be closed as WORKSFORME. The assertion is clearly not valid under all possible conditions, so
even if you cannot reproduce, the code must be written more defensively - or the assert message enhanced to include
information that might point you to the right fix if it happens again. In this case,

            assert getSuiteDirectory() != null;
            ModuleList.refreshModuleListForRoot(getSuiteDirectory());

should be written more defensively as

  File d = getSuiteDirectory();
  if (d != null) {
    ModuleList.refreshModuleListForRoot(d);
  }

since getSuiteDirectory returns null under a variety of conditions and there is no obvious reason why in this situation
it should never be null.
Comment 6 rmichalsky 2009-08-07 14:11:46 UTC
Well, I'd personally rather leave the assertion there than turn it into a condition, this assertion has already revealed
a bug in the code before and situations when it shouldn't hold seem quite obscure to me. But since it is not
reproducible and there is allegedly a rule (which I was not aware of) that it cannot be closed as WORKSFORME, I'll just
write it more defensively.
core-main #51cd17877049
Comment 7 Quality Engineering 2009-08-08 07:03:08 UTC
Integrated into 'main-golden', will be available in build *200908080201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/51cd17877049
User: Richard Michalsky <rmichalsky@netbeans.org>
Log: #169529: fixing AssertionError