Bugzilla – Full Text Bug Listing
| Summary: | [javadoc] "Open External Javadoc" action (Shift-F2) refuses to open valid URL | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Neale Upstone <neale> |
| Component: | Doc | Assignee: | Martin Aeschlimann <martinae> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | dirk_baeumer, wassim.melhem |
| Version: | 3.1 | ||
| Target Milestone: | 3.1 RC2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Neale Upstone
I think I stumbled upon the same bug. I create my how IClasspathContainer returning entries using the new API : JavaCore.newLibraryEntry(IPath path, IPath sourceAttachmentPath, IPath sourceAttachmentRootPath, IAccessRule[] accessRules, IClasspathAttribute[] extraAttributes, boolean isExported) and the Javadoc set in extraAttributes appears correctly in the project build path properties but the system fails to open it when Shift + F2 pressed. It says the same message. I have tried it on the "Plug-in Dependencies" libraries container and the behaviour is the same. If you set a library javadoc though project properties, this fails.... please give this bug a higher priority as I think it is critical for the next major 3.1 release. I think 'http://www.junit.org/junit/javadoc/3.8.1' should be the path to specify: The root folder, not the index.html. Is that the problem? seb.fr (comment 1 and comment 2): Are you setting the Javadoc location programatically or through the user interface? Please paste the resulting .classpath file. First, thank you for looking at this issue. The problem arise both from programatic and the user interface. I first discovered it from programatic point but here is a way to reproduce it using the user interface and 3.1M7 build. - Create a new java project. - edit project properties and java Build path. - in libraries tab, add an external jar, i added org.eclipse.jdt.ui_3.1.0.jar. - then edit it's javadoc location. - select javadoc in archive and choose configure it correctly : I added \Eclipse3.1M7\plugins\org.eclipse.jdt.doc.isv_3.1.0\doc.zip, and path within archive is reference/api. - then close properties dialog and open one of the jar class : org.eclipse.jdt.ui.wizards.BuildPathDialogAccess and select the class name - then invoke Shift+F2 and look a the failure message. here is the .classpath where you'll find the result of the above procedure. <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path=""/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="lib" path="D:/Program Files/Eclipse3.1M7/plugins/org.eclipse.jdt.ui_3.1.0.jar"> <attributes> <attribute value="jar:file:/D:/Program Files/Eclipse3.1M7/plugins/org.eclipse.jdt.doc.isv_3.1.0/doc.zip!/reference/api" name="javadoc_location"/> </attributes> </classpathentry> <classpathentry kind="output" path=""/> </classpath> As I said previously, my first discovery of this issue was building the jar and it's javadoc programmaticaly. I does not matter wether it is programatic and wether the javadoc is in an archive or not. Hope this helps. SeB. I just followed your steps exactly but when I press Shift + F2 in the package explorer or from a reference in the editor, the browser opens correctly. This is RC1 and using Firefox as browser. What does the message say. Can you still reproduce that in RC1? Please reopen if you have an idea whats different. <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"> </classpathentry> <classpathentry kind="lib" path="C:/devel/sdk50512-2035/eclipse/plugins/org.eclipse.jdt.ui_3.1.0.jar"> <attributes> <attribute value="jar:file:/D:/doc files/doc.zip!/reference/api" name="javadoc_location"/> </attributes> </classpathentry> <classpathentry kind="output" path="bin"/> </classpath> The bug is still there when doing programatic javadoc assignment to a library.
The User interface assignament is OK now in RC1 but programatic still does not work.
My code creates a dynamic container
class MhdkLibraryClasspathContainer implements IClasspathContainer {
.....
}
the public IClasspathEntry[] getClasspathEntries() method
returns an array made as follow
entriesList.add(JavaCore.newLibraryEntry(libPath, null, null, null,
new IClasspathAttribute[]{new JavadocAttribute(doc != null ? new File(doc)
.toURL().toString() : null)}, false));
with the following inner class
private static class JavadocAttribute implements IClasspathAttribute {
String myDocPath;
public JavadocAttribute(String path) {
myDocPath = path;
}
public String getName() {
return IClasspathAttribute.JAVADOC_LOCATION_ATTRIBUTE_NAME;
}
public String getValue() {
return myDocPath;
}
}
This is critical to me, and I do not know how to reopen this bug.
If this as not been reopened by tomorow, I will enter a new bug.
Thank a lot for following this.
SeB.
Note that IClasspathAttribute is probably not intended to be subclassed. Only use JavaCore.newClasspathAttribute(). This probably won't solve your problem, as I supect some problem with the classpath container. Set a breakpoint in OpenExternalJavadocAction.run to see where if the classpath entrry is found and the Javadoc attribute correctly retieved. I found the Eclipse Bug
the folowing method is asserting too much on classpath entries
public static URL getJavadocBaseLocation(IJavaElement element) throws
JavaModelException {
:
:
if (entry.getEntryKind() == IClasspathEntry.CPE_CONTAINER) {
entry= JavaModelUtil.getClasspathEntryToEdit(root.getJavaProject(),
entry.getPath(), root.getPath());
if (entry == null) {
return null;
}
}
:
:
}
The method JavaModelUtil.getClasspathEntryToEdit should not be the one to use here.
Why getting an editable classpath entry to get the javadoc? my classpath entry
is not editable but has a javadoc attached to it.
I hope this will be corrected soon.
Oups forgot to tell which class the faulty method comes from : org.eclipse.jdt.internal.corext.javadoc.JavaDocLocations. Dirk, I would fix that for RC2. API method JavaDocLocations.getJavadocBaseLocation should just return a location, not care if the corresponding container is editable. The API is in fact JavaUI.getJavadocBaseLocation() calling JavaDocLocations.getJavadocBaseLocation Approved since the API isn't usasble in this way. approved by Dirk and released > 20050602 JavaDocLocations.getJavadocBaseLocation has now its own JavaModelUtil.getClasspathEntryToEdit that does not check if the container is updatable. Thanks for the help. Can this be closed? My original scenario is no longer valid, but it does look like it got fixed. Marking as closed, then. |