Bug 464439 - [javadoc] Image in JavaDoc not displayed for jars when images are in src.jar
Summary: [javadoc] Image in JavaDoc not displayed for jars when images are in src.jar
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.8.2   Edit
Hardware: All All
: P5 normal with 3 votes (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
: 545882 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-04-11 07:37 EDT by Frank Benoit CLA
Modified: 2023-09-14 04:04 EDT (History)
7 users (show)

See Also:


Attachments
Example JAR (1.16 KB, application/java-archive)
2015-04-11 07:37 EDT, Frank Benoit CLA
no flags Details
JavaDoc OK from sources (8.12 KB, image/png)
2015-04-11 07:39 EDT, Frank Benoit CLA
no flags Details
JavaDoc Fail from jar (3.89 KB, image/png)
2015-04-11 07:40 EDT, Frank Benoit CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Benoit CLA 2015-04-11 07:37:32 EDT
Created attachment 252313 [details]
Example JAR

Hi

in this forum message i illustrated the problem:
https://www.eclipse.org/forums/index.php?t=msg&th=1065506&goto=1691978&#msg_1691978
Comment 1 Frank Benoit CLA 2015-04-11 07:39:01 EDT
Created attachment 252314 [details]
JavaDoc OK from sources

this is when hoovering over a source that links to an image
Comment 2 Frank Benoit CLA 2015-04-11 07:40:19 EDT
Created attachment 252315 [details]
JavaDoc Fail from jar

When the JAR is used in a client project,
the JavaDoc text is shown, be refering to an image not.
Comment 3 Frank Benoit CLA 2015-04-18 04:01:48 EDT
The problem is, that the images are shown with a browser widget, which cannot access the images in a jar.

The HTML is gathered here:
/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/infoviews/JavadocView.java
getJavadocHtml()

A solutions could be
1. extract the image, write it to disk, change the reference in the <img> tag. But I think there would be more problems. Like "when to delete the files", "what about deeper nesting?" ...

2. Embed the image directly as Base64 into the HTML.
<img src="doc-files/sample2.gif" >
would be
<img src="data:image/gif;base64,R0lGODlhEAA....QQA7" >
No temp files. The reference can be evaluated where the JavaDoc is gathered.

So solution (2) seems better.

Are there alternative ways to solve?

What is the preferred way to have Base64 encoding available in that plugin?
As show here http://stackoverflow.com/questions/469695/decode-base64-data-in-java there are many ways:
- adding a dependency to com.google.guave?
- adding a dependency to org.apache.commons.codec?
- use java6 javax.xml.bind.DatatypeConverter? not possible jdt.ui is java5
- use java8 java.util.Base64? not possible jdt.ui is java5
- adding a utility class into jdt.ui? << preferred ?

I can start to work on a patch.
Comment 4 Eclipse Genie CLA 2015-04-25 10:43:06 EDT
New Gerrit change created: https://git.eclipse.org/r/46483
Comment 5 Markus Keller CLA 2015-04-29 18:12:58 EDT
It's quite unusual to have .class files, .java files, and doc-files all together in a single JAR.

In most cases, projects produce a JAR with .class files, a src.zip with source files, and a doc.zip with generated Javadoc. The doc.zip then also contains the doc-files.

JDT already supports loading images from the doc.zip via the integrated help server, see org.eclipse.jdt.internal.corext.javadoc.JavaDocLocations#getBaseURL(..).

For your specific case, you can just open the Properties dialog on the JavaDocExample.jar and then set the JavaDocExample.jar as its own Javadoc location (Javadoc in Archive).

> - use java6 javax.xml.bind.DatatypeConverter? not possible jdt.ui is java5
That would have been the solution, since jdt.ui will soon move to 1.7.
Comment 6 Andrey Loskutov CLA 2016-11-09 11:37:34 EST
(In reply to Markus Keller from comment #5)
> It's quite unusual to have .class files, .java files, and doc-files all
> together in a single JAR.

Interestingly our application hits now same issue, so it seem to be not that unusual :-).

> > - use java6 javax.xml.bind.DatatypeConverter? not possible jdt.ui is java5
> That would have been the solution, since jdt.ui will soon move to 1.7.

AFAIK we are at 1.8 now, so we could also use java.util.Base64

Beside this extra Base64 class which we can get for free now, what speaks against the proposed patch? This seem to be small enough, but makes our life much more convenient. Any objections if I revive the patch?
Comment 7 Missing name CLA 2019-03-28 17:58:22 EDT
Is there any chance to get this fixed?

It seems I run into this problem in https://github.com/reactor/reactor-core/issues/1638
Comment 8 Andrey Loskutov CLA 2019-03-28 18:04:28 EDT
(In reply to Missing name from comment #7)
> Is there any chance to get this fixed?

Sure, just contribute a high quality patch and ask for a review.
Comment 9 Dani Megert CLA 2019-03-31 12:42:16 EDT
*** Bug 545882 has been marked as a duplicate of this bug. ***
Comment 10 Eclipse Genie CLA 2021-09-23 07:26:32 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 11 Eclipse Genie CLA 2023-09-14 04:04:38 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.