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 134899 - Freeze trying to close project
Summary: Freeze trying to close project
Status: RESOLVED WONTFIX
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Milos Kleint
URL:
Keywords: THREAD
Depends on:
Blocks:
 
Reported: 2008-05-13 01:45 UTC by Jesse Glick
Modified: 2008-06-27 11:56 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Thread dump (19.43 KB, text/plain)
2008-05-13 01:45 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2008-05-13 01:45:33 UTC
Dev build, JDK 6, Mevenide installed. Tried to close a newly created (NBM) project using Alt-F C. IDE froze. Thread
dumps reveal something about Maven projects. I do have some project groups (not currently active) using Maven projects.
Comment 1 Jesse Glick 2008-05-13 01:45:51 UTC
Created attachment 61299 [details]
Thread dump
Comment 2 Jesse Glick 2008-05-13 01:46:52 UTC
IDE came back to life a few minutes later. Note that I have a working internet connection, so I am not sure why it is
hung here (though of course nothing ought to be making network calls in EQ to begin with).
Comment 3 Milos Kleint 2008-05-13 06:54:39 UTC
not really sure what I can do there.


1. the stacktrace shows that a certain maven project is being loaded. in general the project loading avoids touching the
network, with 2 exceptions. parent poms and extensions (these defined packaging) which are necessary for correct project
loading.
2. even parent poms and extensions are only checked when not present locally. one exception to the rule could be when
you are using a SNAPSHOT extension and the remote repo is checked for update. (I guess I could force no update checking
here)
3. for most projects this project loading happens either on startup where it's lazy and out of AWT or when creating the
project which also happens out of AWT.

I think that in this case the primary problem and place to fix the issue is the
org.netbeans.modules.project.ui.groups.SubprojectsGroup class which should somehow cache the title value.


Comment 5 Jesse Glick 2008-05-14 01:36:08 UTC
I don't think it should ever block on a network connection. SubprojectsGroup should not have to cache the title. There
probably _is_ a problem that the submenu was calculated just because I posted the File menu. This is very undesirable of
course: there is no reason to determine the contents of the submenu unless it is posted.
Comment 6 Milos Kleint 2008-05-14 08:31:53 UTC
well, in order to get the project name I need to load the project model (along with all parents poms that this one
inherits from, if these are not present locally these *have* to be downloaded or the model falls apart. the model is
cached until rendered obsolete. The model replacement is done asynchronosly, however the first time loading can under
certain conditions (this being the first one I know of) happen in AWT. As I mentioned earlier, for most common scenarios
it's happening early in the project's lifetime and is done away from AWT. I don't see a way to change the project
loading to satisfy this usecase on maven side, closing as WONTFIX.
Comment 7 Jesse Glick 2008-05-14 17:00:30 UTC
If determination of the correct project name cannot happen without accessing the network, the project type should return
some placeholder string, such as the name of the project directory.

I am still unable to determine what actual project is involved here. The only candidate I can see is

kind=subprojects
path=file:/space/src/hudson/

which does not specify a name in the group definition. But /space/src/hudson/pom.xml clearly states

<packaging>pom</packaging>
<name>Hudson</name>

which ought to be everything Mevenide needs to know. Your comments suggest that you load a complete project model just
to report the name of the project, which seems like overkill when the name is just a simple field in the XML.
Comment 8 Milos Kleint 2008-05-14 19:24:43 UTC
well, the name could be defined in parent's pom parent and it could be defined like this:
<name>Hudson - ${artifactId}</name>
Only when the complete project is loaded and variables get replaced I can figure the real value.

Comment 9 Jesse Glick 2008-05-14 20:17:43 UTC
I suppose the name could hypothetically be defined in such a way, though that is not my case.
Comment 10 Lukas Hasik 2008-06-27 11:56:11 UTC
x