Bug 250950 - Javadoc location unconfigured error should allow for easily supplying a javadoc location
Summary: Javadoc location unconfigured error should allow for easily supplying a javad...
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.4.1   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2008-10-15 10:37 EDT by Aleksander Adamowski CLA
Modified: 2008-10-16 10:28 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aleksander Adamowski CLA 2008-10-15 10:37:39 EDT
Build ID: M20080911-1700

Steps To Reproduce:
Suppose that a user in the Java editor selects an element from an external library, and that library doesn't have a javadoc location set (a common situation with Maven-managed dependencies)

Then he presses "Shift-F2" to open the element's javadoc.

Currently he'll receive a somewhat unhelpful error:

==== Open External Javadoc ===== 

The documentation location for 'SELECTED_ELEMENT' has not been configured. For elements from libraries specify the Javadoc location URL on the properties page of the parent JAR ('PATH/TO/CONCRETE/JAR.jar')
================================ 

Suppose that the user knows the URL to the API javadocs for that JAR (or has a local javadoc archive).

In order to correct this situation, the user has to separately locate the corresponding JAR in the Eclipse classpath container (e.g. in Project Explorer), in order to invoke its properties, where he can set the javadoc location and/or add a source attachment.

This can be extremely labour intensive if the project has dozens of libraries on the build path. Imagine locating a single jar by name in a "Maven Dependencies" container that holds over 100 libraries! 

To make it even harder, libraries aren't displayed in alphabetic order, in fact they don't seem to be in any order at all.

I think that the "Open External Javadoc" error window should provide a hyperlink that opens the properties dialog for the reported JAR's classpathcontainer, where the user can supply the missing javadoc location settings (and, if needed, source attachment).

There already are similar hyperlinks to relevant configuration dialogs in some other error messages that Eclipse reports, so apparently UI components required for this already exist in Eclipse.

More information:
Comment 1 Markus Keller CLA 2008-10-16 05:20:14 EDT
I agree that the workflow is not well supported, but it's not that awkward:

> In order to correct this situation, the user has to separately locate the
> corresponding JAR in the Eclipse classpath container [..]
> This can be extremely labour intensive if the project has dozens of libraries
> on the build path. [..]

You can
- open the element (F3)
- choose Navigate > Show In > Package Explorer
- walk up the tree to the JAR

> To make it even harder, libraries aren't displayed in alphabetic order, in fact
> they don't seem to be in any order at all.

They are in the order in which they have been added to the class path.

> I think that the "Open External Javadoc" error window should provide a
> hyperlink that opens the properties dialog for the reported JAR's
> classpathcontainer, where the user can supply the missing javadoc location
> settings (and, if needed, source attachment).

Or add a question "Do you want to configure the Javadoc location?" with OK/Cancel.
Comment 2 Aleksander Adamowski CLA 2008-10-16 10:28:46 EDT
>> I think that the "Open External Javadoc" error window should provide a
>> hyperlink that opens the properties dialog for the reported JAR's
>> classpathcontainer, where the user can supply the missing javadoc location
>> settings (and, if needed, source attachment).
>
> Or add a question "Do you want to configure the Javadoc location?" with
> OK/Cancel.

Whatever is more consistent with the current Eclipse behaviour in similar situations. The hyperlink style is consistent with the popups that e.g. alert about updates to be installed. I think it was also used in a similar error pop up relatied to some other aspect of configuration.