Bug 193579 - Maven POM Autocompletion
Maven POM Autocompletion
Status: RESOLVED FIXED
Product: cnd
Classification: Unclassified
Component: Project
7.0
PC Windows 7 x64
: P3 (vote)
: 7.0
Assigned To: Alexander Simon
issues@cnd
: PERFORMANCE, THREAD
Depends on: 183681
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-18 17:46 UTC by Blackpanther
Modified: 2011-02-17 16:51 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Thread Dump taken during bug (32.87 KB, application/octet-stream)
2011-01-13 22:11 UTC, Blackpanther
Details

Note You need to log in before you can comment on or make changes to this 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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo