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.
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.
Created attachment 122101 [details] Diff file
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.
[TM01] Call ProjectProblems.showAlert() in icon annotator so it is shown automatically for all API users.
In reply to comment #3. Makes sense, I am adding it.
Created attachment 122171 [details] Diff file Resolved Tomas Mysik request.
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.
[TM02] Once a problem is resolved, The Resolve... button should be disabled for it.
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.
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.
[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.
[TM02] OK, I see.
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.
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.
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.
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.
Created attachment 122267 [details] Resolve Binary/Source Format Dialog
I will integrate the API tomorrow.
(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. :-)
(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...
(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.
Fixed jet-main 177ad566125d Fixed jet-main 0745cb62239f
(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.
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