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.
| Summary: | Ability to resolve a broken library reference in a customized manner | ||
|---|---|---|---|
| Product: | java | Reporter: | Jesse Glick <jglick> |
| Component: | Project | Assignee: | Jesse Glick <jglick> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | anebuzelsky, apireviews, dkonecny |
| Priority: | P2 | Keywords: | API, API_REVIEW_FAST |
| Version: | 7.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 206786 | ||
| Attachments: |
Proposed patch, minus apichanges
Sample implementation using Plugin Manager Sample implementation using Maven |
||
Created attachment 105374 [details] Sample implementation using Plugin Manager The referenced NBM is assumed to contain the library JAR and definition and should be placed on an accessible update center. Bug #194518 would simplify the implementation and improve the UI. Created attachment 105375 [details]
Sample implementation using Maven
[DK1] - patch does not provide more ways to resolve broken library references. It replaces current "define a new library" behavior with a different one - "download a library from somewhere" (if certain criteria are matched). If we assume that users will be always online and happy with downloading library then it is fine. Alternative would be to provide both ways how to resolve broken library and let user decide, for example keep "Resolve" button with old behaviour and add a second button "Download" for new behaviour. [DK2] - patch does not solve well the usecase you gave: "Ship a sample project template using an exotic library which is large and otherwise unused, and therefore not physically shipped with the IDE.". When user finishes New Project wizard of such sample project they are given project with a broken library reference. It would be better to perform download operation semi-automatically without forcing user to go through Resolve Broken References workflow. DK1 - if the definer returns null for a given library then the former UI is presented. If it returns a Callable, the new message is presented in the dialog, but if that Callable throws an exception rather than returning a library then the Library Manager dialog is presented as before. DK2 - you can already do that if you want it, but it is not appropriate if the user needs to agree to the operation. Seems good to me. DK1 - yes, that's what I'm objecting to, that UI forces certain workflow which we designed to solve one particular problem but user's desires might be different. But it is only UI and proposed API supports both UI cases so I'm fine with the change. Y01 No tests. Y02 No apichanges.xml Y03 Not mentioned in arch.xml as exporeted category="lookup" Y04 Are the locations org-netbeans-api-project-libraries/Downloads/ and org-netbeans-api-project-libraries/Maven/ part of some existing API? Y01 - this is GUI not generally tested. Y02 - I know, as mentioned in patch description; apichanges entry would be added prior to commit. Y03 - This is silly, we do not enumerate everything that could be in default lookup in arch.xml files. The Javadoc for the new interfaces specifies how it may be used. Y04 - no. Those locations are mentioned only as part of the demo patches, which are not under review except as proof of concept for LibraryDefiner. core-main #63b8a9dda946 Integrated into 'main-golden', will be available in build *201102040000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/63b8a9dda946 User: Jesse Glick <jglick@netbeans.org> Log: #194744: ability to resolve a broken library reference in a customized manner. |
Created attachment 105373 [details] Proposed patch, minus apichanges Currently the Broken References dialog only offers a predefined list of resolutions. This is limiting. For example, currently if you ship a sample project template using an exotic library which is large and otherwise unused, you are also forced to include that library definition, which forces you to ship that physical library. Asking the user to manually download the right JARs and define the library is impolite. Adding a New Project wizard step to define the library is a possibility but means that you would not want to remove a bundled library you used to ship for this purpose, as you would break previously created samples. Automatically defining the library when a project using it is opened would bypass the usual Broken References UI, which would be particularly irritating if a license must be accepted or some other user interaction is required. The attached patch would make it possible to ship only the sample project; you would provide a callback for the Broken References dialog which would somehow retrieve the JARs and define the matching library if "Resolve" is clicked. You can write such a callback from scratch, though for purposes of review I will include two add-on patches (not proposed in this issue) providing standard implementations that make it easy to register a particular library. The patch only handles the case of a missing library definition. Other kinds of problems, such as libraries with missing or invalid volumes, could be handled with separate SPIs in the same style if it turns out to be useful.