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 193579

Summary:	Maven POM Autocompletion
Product:	cnd	Reporter:	Blackpanther
Component:	Project	Assignee:	Alexander Simon <alexvsimon>
Status:	RESOLVED FIXED
Severity:	normal	CC:	alexvsimon, jglick
Priority:	P3	Keywords:	PERFORMANCE, THREAD
Version:	7.0
Hardware:	PC
OS:	Windows 7 x64
Issue Type:	DEFECT	Exception Reporter:
Bug Depends on:	183681
Bug Blocks:
Attachments:	Thread Dump taken during bug

Description Blackpanther 2010-12-18 17:46:06 UTC

Product Version = NetBeans IDE 7.0 Beta (Build 201011152355)
Operating System = Windows 7 version 6.1 running on amd64
Java; VM; Vendor = 1.6.0_21
Runtime = Java HotSpot(TM) 64-Bit Server VM 17.0-b16

When I want to modify a maven project by navigating projet properties, the IDE get stuck at updating the POM.

Comment 1 Marian Mirilovic 2011-01-05 08:55:14 UTC

could you please attach thread-dump when the IDE is stuck ?
http://wiki.netbeans.org/GenerateThreadDump

Comment 2 Blackpanther 2011-01-13 22:11:17 UTC

Created attachment 104978 [details]
Thread Dump taken during bug

Comment 3 Blackpanther 2011-01-13 22:12:29 UTC

When I tried to generate thread dump by pressing Ctrl+Break in my console window, an error were generated but the POM completion worked.

Comment 4 Jesse Glick 2011-01-14 21:09:58 UTC

MakeProjectFileOwnerQuery.getOwner must not call OpenProjects.getOpenProjects. Generally FOQ impls should avoid any reliance on the open project list, but where it is necessary to pay attention to open projects to disambiguate choices, you need to listen to changes in the set of open projects and make the actual gO call fast and nonblocking.

Comment 5 Alexander Simon 2011-01-14 22:42:28 UTC

(In reply to comment #4)
> MakeProjectFileOwnerQuery.getOwner must not call OpenProjects.getOpenProjects.
> Generally FOQ impls should avoid any reliance on the open project list, but
> where it is necessary to pay attention to open projects to disambiguate
> choices, you need to listen to changes in the set of open projects and make the
> actual gO call fast and nonblocking.
API do not mentioned that "FileOwnerQueryImplementation.getOwner()" must not call OpenProjects.getOpenProjects.
So it is not MakeProjectFileOwnerQuery issue.

Comment 6 Alexander Simon 2011-01-14 23:54:54 UTC

It seems OpenProjects.getOpenProjects() violates "Command Query Separation" principle (see http://en.wikipedia.org/wiki/Command-query_separation).

Comment 7 Jesse Glick 2011-01-15 00:33:54 UTC

(In reply to comment #5)
> API do not mentioned that "FileOwnerQueryImplementation.getOwner()" must not
> call OpenProjects.getOpenProjects.

Fixed in core-main #abd2a3c89640. Now please fix your impl.

Comment 8 Alexander Simon 2011-01-16 04:20:13 UTC

(In reply to comment #7)
> Fixed in core-main #abd2a3c89640. Now please fix your impl.
1. Your change set introduced significant constraint. It is unacceptable for API. Did changes pass API review?
IMHO you should deprecate class and introduce new "lite weight File Owner Query Implementation".
2. Root of issue is *blocking* method OpenProjects.getOpenProjects().
Make method nonblocking or provide new nonblocking version of the method.

Comment 9 Jesse Glick 2011-01-19 17:50:44 UTC

(In reply to comment #8)
> Your change set introduced significant constraint.

No, this constraint has been there since the project system was designed in 4.0, it just was not mentioned in this particular piece of Javadoc. The infrastructure layer (incl. FOQ) should not call into the UI layer (incl. OPL).

When I get a chance I will prepare a patch to MakeProjectFileOwnerQuery and reassign for review. P1s & P2s come first, though.

Comment 10 Alexander Simon 2011-02-17 15:03:55 UTC

fixed when Bug #195505 was fixed.

Comment 11 Jesse Glick 2011-02-17 16:02:40 UTC

Not sure I understand 21982ffd50a9 well enough to really comment, but this sounds like the right approach, more or less in line with comment #4. The idea is that "low-level" APIs such as file ownership, queries, etc. should not depend on "high-level" APIs such as which projects are open in the GUI. Where for performance or logistical reasons it is impractical to compute information needed for a low-level API for nonopen projects, the low-level API should attempt to gracefully return incomplete information, with project open events being used as a hint to guide which calculations should proceed.

For example, Maven projects claim ownership of artifacts in the local repository that their build would produce (needed for the Java editor), but the source project location cannot be guessed from the artifact itself; in 6.x this FOQI checked the open project list directly, which caused a lot of problems, so in 7.0 there is rather an artifact -> source cache which is updated when a project is opened.

Comment 12 Vladimir Voskresensky 2011-02-17 16:28:17 UTC

(In reply to comment #11)
> For example, Maven projects claim ownership of artifacts in the local
> repository that their build would produce (needed for the Java editor), but the
> source project location cannot be guessed from the artifact itself; in 6.x this
> FOQI checked the open project list directly, which caused a lot of problems, so
> in 7.0 there is rather an artifact -> source cache which is updated when a
> project is opened.
Is this artifact supported somehow by Project API or it's in Maven only? Where can I have a look?

Thanks,
Vladimir.

Comment 13 Jesse Glick 2011-02-17 16:51:29 UTC

(In reply to comment #12)
> Is this artifact supported somehow by Project API or it's in Maven only?

Maven only.

> Where can I have a look?

maven/src/org/netbeans/modules/maven/queries/MavenFileOwnerQueryImpl.java

where registerProject is called from the project's open hook.