Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 Build Identifier: 20090920-1017 I have a user library (ATG Dynamo 2007.1) with several jars, which is used by several projects in my workspace. When I hover on a reference to one of those classes, it says "... the javadoc could not be found in the attached javadoc." The javadoc for these classes is available at a URL in my network. I verified the URL in the browser (including that it includes the class I was hovering over), and I went to the User Library definition and clicked "Edit" on the "Javadoc location" for the jar that contains the particular class that I was hovering over. After pasting in the URL into the "javadoc location path" I clicked "Validate", and it said "Location is likely valid". After storing all that, I hovered on the class name reference again, and it said "... the javadoc could not be found in the attached javadoc." The ATG Dynamo library and its javadoc is not generally available, but I'll attach some of the pieces that I can see. Reproducible: Always
Created attachment 151097 [details] archive containing the "root" files of the ATG javadoc
(In reply to comment #0) > After pasting in the URL into the "javadoc location path" I > clicked "Validate", and it said "Location is likely valid". Just curious, could you try the "Open In Browser", when you get the validate confirmation dialog? Please let me know if this works fine.
Yes, that displays the javadoc frames page in my browser, as normal.
The attached file won't help as it doesn't provide the javadoc for the types themselves. I'll request access to the ATG Dynamo 2007.1 user library to try to reproduce it. Do you have any entry in the .log file ?
Would it be possible to get the javadoc entry corresponding to a type for which there is no javadoc available?
There is no corresponding information in the .log file. There are no obvious error messages there, or any message that might be related to this. I'm not sure how to respond to the question about a javadoc entry for a type with no javadoc. I'm testing this with a type that has javadoc, the "RepositoryItem" class (which will be useful if you get access to the javadoc).
Created attachment 151517 [details] Javadoc page for class that Eclipse says there is no javadoc for
I finally realized what you were asking, so I'm attaching "RepositoryItem.html".
What part of the javadoc are you trying to display when hovering on a reference? The type itself? one of its methods ? fields ? I am trying to build a test case to reproduce your issue.
My simplest test is just hovering over the class name.
Created attachment 151859 [details] Proposed fix Would you be able to test that patch? It seems to work for me, but I would like you to try different types, methods and field references.
Daniel, this is a good candidate for 3.5.2. When javadoc is using lowercase html tags, we cannot locate the javadoc for java elements. It seems that newer versions of the javadoc tool is using lowercase html tags instead of uppercases (<a name="..."> vs <A NAME="...">). This is the cause of this problem. We need to support both cases.
Adding Daniel on CC list as I requested PMC approval for backporting it to 3.5.x.
I have never attempted to integrate Eclipse patches, or even build it from source. I've done this for other smaller non-Eclipse projects in the past, but not this. I'm willing to try, but I imagine this is a very large effort. Can you point me down that road as far as possible? I don't understand the comments here about lowercase vs. uppercase HTML tags. I compared my "RepositoryItem.html" with the "HashMap.html" from the JDK javadoc, and I didn't see any patterns where one was using lowercase and the other uppercase. In fact, I saw both lowercase and uppercase usage in both. Are these comments referring to lowercase tags in a different file than the "base" javadoc HTML file for each class?
If you check the anchor for the CLASS_VERSION field in your type documentation, you will see that it is using <a name="... In the code we were looking for <A NAME="..., and we could not find it since we were doing case sensitive search. Adding case insensitive seems to fix it for this specific case. Would you be fine to test next week integration build ?
I am fine with testing an integration build, if I know when to get it, where to get it from, and how to install it (I imagine the latter is the easiest part).
Actually, I realized something else I can test. Although I only have a URL for the javadoc, I can use "wget" to recursively download it, then I'll modify it to use uppercase tags, and then point my jar to that javadoc. I still want to test the integration build (if someone tells me how to do that), but I'll test this way also.
(In reply to comment #17) > Actually, I realized something else I can test. Although I only have a URL for > the javadoc, I can use "wget" to recursively download it, then I'll modify it > to use uppercase tags, and then point my jar to that javadoc. I still want to > test the integration build (if someone tells me how to do that), but I'll test > this way also. I'll let you know as soon as the integration build that contains this fix is available. If you replace all usage of "<a name=" with "<A NAME=" and "</a>" with "</A>", the existing code should work.
Acknowledged. Now I just have to figure out how to get wget to download the directory tree correctly. The obvious command line is copying some files in directories to a file in the root directory with an odd name (with "@" and "%2f" separators).
(In reply to comment #13) > Adding Daniel on CC list as I requested PMC approval for backporting it to > 3.5.x. AFAIK all known versions of the javadoc tool generate uppercase tags. Of course someone could use a different mechanism to generate Javadoc but since we've not heard of a similar issue for years, this is just not major enough to backport.
(In reply to comment #20) > AFAIK all known versions of the javadoc tool generate uppercase tags. Of course > someone could use a different mechanism to generate Javadoc but since we've not > heard of a similar issue for years, this is just not major enough to backport. The doc example I got contains this line: <!-- Generated by javadoc (build 1.5.0_11) on Mon Jul 09 23:58:30 EDT 2007 --> And the html tags are lowercase. Not backporting it means that the user cannot retrieve the javadoc in the case of lowercase tags. I'll release the fix for HEAD.
Released for 3.6M4. David, you will need to verify it as you are the only one we know that has a doc with lowercase tags.
I will, but I'm having some trouble with this issue, as I'm having trouble reproducing the problem. I had been spending time working with the locally-saved copy of the javadoc tree, when I realized I wasn't seeing the symptom with the lowercase tags. I then tried setting the javadoc URL back to the HTTP version, and I still can't repeat the problem. I've even tried restarting Eclipse.
I clearly got the problem with the attached javadoc and the problem is fixed with the attached patch. The test case I used is the following: import atg.repository.RepositoryItem; public class X { public static void main(String[] args) { RepositoryItem item = null; System.out.println(item.CLASS_VERSION); } } I opened the javadoc view and I selected on the the CLASS_VERSION. Before the patch I would get the error saying that the current field has no javadoc. With the patch, I could get the expected javadoc.
I believe you, and that's the behavior that I was seeing initially, even after I set up the javadoc URL on the jar file. At some point that I can't determine, I was no longer seeing that symptom, even after I went back to using the original HTTP URL for the javadoc. I'm not sure what that means.
Verified for 3.6M4 via code inspection.
