Bug 215628 - Provide generic API and UI for solving project metadata problems
Provide generic API and UI for solving project metadata problems
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Generic Projects UI
7.3
All All
: P3 (vote)
: 7.3
Assigned To: Tomas Zezula
issues@projects
: API, API_REVIEW_FAST
Depends on:
Blocks: 216114 215665
  Show dependency treegraph
 
Reported: 2012-07-17 12:55 UTC by Tomas Zezula
Modified: 2012-07-30 05:50 UTC (History)
6 users (show)

See Also:
Issue Type: TASK
:


Attachments
Diff file (224.02 KB, patch)
2012-07-17 13:01 UTC, Tomas Zezula
Details | Diff
Diff file (231.25 KB, patch)
2012-07-18 16:28 UTC, Tomas Zezula
Details | Diff
Diff file (265.42 KB, patch)
2012-07-23 13:07 UTC, Tomas Zezula
Details | Diff
Resolve Binary/Source Format Dialog (35.90 KB, image/png)
2012-07-23 13:08 UTC, Tomas Zezula
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2012-07-17 12:55:53 UTC
Currently the UI and API for managing project metadata problems is in java.project module and is java (ant) specific. The UI should be moved into Project UI module, a new API should be created in the Project UI API module. The java.project methods should be deprecated and bridged to the new API. Support factory methods should be added into java.project as a replacement of deprecated methods.
Comment 1 Tomas Zezula 2012-07-17 13:01:33 UTC
Created attachment 122101 [details]
Diff file
Comment 2 Tomas Zezula 2012-07-17 13:10:21 UTC
Implemented as described above.
Added interface ProjectProblemsProvider. Implementations of the ProjectProblemsProvider are registered in the Project lookup as well as the merger for them, created by the factory method UILookupMergerSupport::createProjectProblemsProviderMerger. The ProjectProblemsProvider creates project metadata problems (ProjectProblemsProvider.Problem). When project has some metadata problem the project is marked as broken and "Resolve Project Problems" action is enabled. Each problem can be resolved by the ProjectProblemResolver.

The existing java specific BrokenReferencesSupport methods are bridged to the new API and deprecated.
Factory methods are added into BrokenReferencesSupport to create ProjectProblemsProviders doing the same work as the deprecated methods.
Comment 3 Tomas Mysik 2012-07-17 15:25:00 UTC
[TM01] Call ProjectProblems.showAlert() in icon annotator so it is shown automatically for all API users.
Comment 4 Tomas Zezula 2012-07-17 16:00:35 UTC
In reply to comment #3.
Makes sense, I am adding it.
Comment 5 Tomas Zezula 2012-07-18 16:28:49 UTC
Created attachment 122171 [details]
Diff file

Resolved Tomas Mysik request.
Comment 6 Tomas Zezula 2012-07-18 16:32:41 UTC
When the project has the ProjectProblemsProvider in the lookup the "broken project" alert is shown automatically. No need to have the copy paste alert logic in ProjectOpenHook.
Comment 7 Tomas Mysik 2012-07-19 05:19:17 UTC
[TM02] Once a problem is resolved, The Resolve... button should be disabled for it.
Comment 8 David Konecny 2012-07-20 05:01:26 UTC
Thanks Tomas for doing this. This is very helpful API! Overall it looks good to me.

DK01 - the only thing which caught my attention was ProjectProblemResolver and requirement to implement hashCode and equals. Is it there only so that ProjectProblem can implement those two methods properly? If so would not it be easier to just give ProjectProblem some ID which needs to be unique? Whoever is creating ProjectProblem should be able to easily assign it a unique ID. Btw. why does ProjectProblem has to implement hashCode and equals?

Thanks.
Comment 9 Milos Kleint 2012-07-20 12:56:27 UTC
MK1: is it configurable when to show the alert? in maven projects, there's a lot of problem states of minor severity (eg. some dependencies are not downloaded, missing on classpath) which happen quite often, not only during opening of projects but during the entirely lifecycle. Then there's severe problems like project model is unloadable.

It would be nice to have a way to influence when the alert appearance. Eg by some sort of callback to the project type or by implementing severity on problems.
Comment 10 Tomas Zezula 2012-07-23 09:12:32 UTC
[TM02]: The Resolve button should be always enabled to keep the same  functionality as before.
Here is the reasons pasted from old BRC code:
// Leave the button always enabled so that user can alter 
// resolved reference. Especially needed for automatically
// resolved JAR references.
It makes sense to me, so keeping as it was.
Comment 11 Tomas Mysik 2012-07-23 09:21:52 UTC
[TM02] OK, I see.
Comment 12 Tomas Zezula 2012-07-23 10:00:04 UTC
DK01: Exactly, the ProjectResolver is the only part of the ProjectProblem which can provide reasonable identity. The ProjectProblem itself is final to be extensible. There were 4 possibilities how to do it:

1st) Using covariant non-reifiable type, this was the first way I've selected but it was rather Java Puzzle for the API user. The ProjectProblem.create signature looked like:

public static <T extends Callable<Future<Result>> & Comparable<? super T>> ProjectProblem ProjectProblem.create(String name, String description, T resolver)

2nd) Another possibility was Singletonizer, similar complexity as 1.

3rd) Was the opaque ID (either String - will end with some "unique" part and property name(s) concatenated together or Object correctly implementing the hashCode and equals - in fact there is already such an object the resolver). 

4th) Using the Resolver hashCode and equals and specify it in protocol  by signatures as Map.Entry does.

None of it is nice but I believe that 4th is the less evil.
Comment 13 Tomas Zezula 2012-07-23 10:04:03 UTC
MK1: In Ant based project everything is critical,  so the current design does not allow it.
I agree that it's an legitimate API request so I will extend the API by:


enum Severity {
    ERROR,
    WARNING
}

and add Severity parameter into ProjectProblem.create() factory method.
The alert panel will be shown only if there is at least one ERROR ProjectProblem.
Comment 14 Tomas Zezula 2012-07-23 10:18:32 UTC
DK01 - cont: Sorry I've forgot to answer why the ProjectProblem.equals() is needed.

There are currently two use cases:

1st) Resolve Broken Reference for Folder/Archive may fix more problems when the broken references come from a single folder. The BrokenReferencesCustomizer refreshes the list after the Future<Result> is done and matches new problems to old ones. Those which are missing are also resolved.

2nd) For some PHP problems showing the project customizer it's hard to return even the future of Result, so they return UNRESOLVED and when ProjectProblmesProvider recalculates problems it fires an event and the BrokenReferencesCustomizer tries to match the old and new problems.
Comment 15 Tomas Zezula 2012-07-23 13:07:04 UTC
Created attachment 122266 [details]
Diff file

2 changes:
1st) resolved Milos comment as described above (added enum Severity)

2nd) Added a UI to resolve wrong binary/source format (the BrokenReferenceSupport.createPlatformVersionProblemProvider signature has changed). The UI is shown on attached image.
Comment 16 Tomas Zezula 2012-07-23 13:08:00 UTC
Created attachment 122267 [details]
Resolve Binary/Source Format Dialog
Comment 17 Tomas Zezula 2012-07-23 13:09:00 UTC
I will integrate the API tomorrow.
Comment 18 David Konecny 2012-07-23 19:34:41 UTC
(In reply to comment #14)
> DK01 - cont: Sorry I've forgot to answer why the ProjectProblem.equals() is
> needed[...]

Thanks for the explanation. If equals/hashCode is needed only to display resolved problems in the UI then I would consider changing Broken References UI to not show resolved problems. :-)
Comment 19 Tomas Mysik 2012-07-24 08:29:25 UTC
(In reply to comment #18)
> I would consider changing Broken References UI
> to not show resolved problems. :-)

Well, I tested it a few days ago and - the user experience was not good. The resolved problem simply disappears from the list - what if you made a mistake, how can you fix it? Also, if once resolves a problem with a warning - how to display and possibly fix such warning? The problem is not in the list anymore...
Comment 20 Petr Somol 2012-07-24 08:59:18 UTC
(In reply to comment #19)
> 
> Well, I tested it a few days ago and - the user experience was not good. The
> resolved problem simply disappears from the list - what if you made a mistake,
> how can you fix it? Also, if once resolves a problem with a warning - how to
> display and possibly fix such warning? The problem is not in the list
> anymore...

I agree with comment #19 that resolved problems definitely should not disappear from list.
Comment 21 Tomas Zezula 2012-07-24 12:01:43 UTC
Fixed jet-main 177ad566125d
Fixed jet-main 0745cb62239f
Comment 22 David Konecny 2012-07-24 23:33:38 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > 
> > Well, I tested it a few days ago and - the user experience was not good. The
> > resolved problem simply disappears from the list - what if you made a mistake,
> > how can you fix it? Also, if once resolves a problem with a warning - how to
> > display and possibly fix such warning? The problem is not in the list
> > anymore...
> 
> I agree with comment #19 that resolved problems definitely should not disappear
> from list.

Make sense. Thanks for the explanation.
Comment 23 Quality Engineering 2012-07-26 02:18:02 UTC
Integrated into 'main-golden', will be available in build *201207260002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/177ad566125d
User: Tomas Zezula <tzezula@netbeans.org>
Log: #215628:Provide generic API and UI for solving project metadata problems


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