Community
Participate
Working Groups
When attaching javadoc to a library, the user should be able to specify a jar/zip , along with the root (like attaching source).
Martin, I guess the easiest and best fix would be if the location would allow to point to JARs (including JARs on the web). This would leave the UI as is.
not for 2.1
Reconsidering for 2.2
asking 'help' if we could use the existing infrastructure: possibility to use IHelp.displayHelpResource with a toc that point to a file in a jar. this feature (attach javadoc in a jar) has been wished many times so, in my opinioun, we should do it for 2.2
I think it is possible to implement a simple scheme that allows the help system to resolve a URL to a path to a jar and extract the appropriate topic out of the jar. I can see a problem with jar's located on the web, as this will introduce some security problems: if the files are processed by the help system, then all the pages loaded from the jar would appear as loaded from the same domain as the local files (because it is the help system engine that fetches them). Another problem is downloading the jars by the help system when current host is behind a proxy. This problem has been partially addressed in the update manager, but not in a satisfactory way. If the remote jars requirement is dropped, I think it is worth having the help system investigate a solution.
Are you concerned about running code out of a remote jar? Would it make any difference if it were from a zip instead of a jar?
No, it's not about running code from the jar, but for any potential side- effects for treating everything as being from the same domain. For security reasons browsers do not allow pages from different domains to execute javascript, etc. If we, under the cover, make everyhing appear as belonging to the help webapp, then we are, in effect, bypassing this browser built-in support for cross-domain scripting. I don't have any specific examples of what can go wrong, but this has been put in place for good reasons by all the browser providers. It is perhaps ok to use some sort of permissions (JDT can detect that that's the case, etc.). It would be a bit wrong for the help system to enforce any security constraints there, so my preferred way is to move this issue into JDT. One way to address this, is to have JDT register its own webapp, just like we do in help (update manager also does it for web-triggered updates). They will come up with whatever convention for url's to files inside zip/jars/etc. by mapping URL paths to one or more servlets, and have those servlets deal with extracting the code, deciding on security issues, etc. Help will only provide the means to register webapps (org.eclipse.help.internal.appserver.WebappManager is the class you need), and the browser. Does this make any sense or is an overkill ?
I only had local files in mind when I submitted this one, and would be just fine with that limitation (if for nothing else than a simple fix).
Local files would be fine with me too.
I also only thought of local JARs. It's mostly about the src.zip that you can download with the JDK, but a src.zip on a webserver doesn't really exist as far as I know. (nobody could browse it anyways) So far we successfully avoided to have an own webapp (because we're afraid that its an overkill) but of course I see there are some cool opportunities if we have one. As long as you in the help team don't feel misused I'd be glad if we could continue using the existing help webapp.
That sounds good. We will look at a solution in help and will provide the API/url to use to display files from a jar/zip.
I have added support to help and webapp server to provide contents from local jars. JDT can now ask help to display Javadoc from jars similarly as is doe for flat files with file: protocol. Examples of calls to display a file that is in a jar or zip are: IHelp.displayHelpResource("jar:file:/d:/test.zip!/TestPackage/TestClass.html"); or IHelp.displayHelpResource("topic=jar%3Afile%3A%2Fd%3A%2Ftest.zip!% 2FTestPackage%2FTestClass.html"); Note: Jar URI must point to a file, which means "jar:html:..." is not supported for the reasons discussed above.
I think you meant jar:http above...
Thanks Dorian. Yes. I meant jar:http: Of course, something like jar:html: should not work either.
Thanks Konrad & Dorian!
*** Bug 38298 has been marked as a duplicate of this bug. ***
Feature added in 3.0 M2.
