Bug 194744 - Ability to resolve a broken library reference in a customized manner
Ability to resolve a broken library reference in a customized manner
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Project
7.0
All All
: P2 (vote)
: 7.0
Assigned To: Jesse Glick
issues@java
: API, API_REVIEW_FAST
Depends on:
Blocks: 206786
  Show dependency treegraph
 
Reported: 2011-01-26 16:29 UTC by Jesse Glick
Modified: 2011-12-29 14:57 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Proposed patch, minus apichanges (13.06 KB, patch)
2011-01-26 16:29 UTC, Jesse Glick
Details | Diff
Sample implementation using Plugin Manager (9.22 KB, patch)
2011-01-26 16:32 UTC, Jesse Glick
Details | Diff
Sample implementation using Maven (17.86 KB, patch)
2011-01-26 16:33 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2011-01-26 16:29:55 UTC
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.
Comment 1 Jesse Glick 2011-01-26 16:32:13 UTC
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.
Comment 2 Jesse Glick 2011-01-26 16:33:15 UTC
Created attachment 105375 [details]
Sample implementation using Maven
Comment 3 David Konecny 2011-01-26 22:36:23 UTC
[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.
Comment 4 Jesse Glick 2011-01-26 22:45:04 UTC
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.
Comment 5 Tomas Zezula 2011-01-27 09:24:56 UTC
Seems good to me.
Comment 6 David Konecny 2011-01-27 19:07:35 UTC
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.
Comment 7 Jaroslav Tulach 2011-01-30 18:52:58 UTC
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?
Comment 8 Jesse Glick 2011-01-31 14:26:32 UTC
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.
Comment 9 Jesse Glick 2011-02-03 02:56:41 UTC
core-main #63b8a9dda946
Comment 10 Quality Engineering 2011-02-04 05:58:28 UTC
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.


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