Community
Participate
Working Groups
Fup of bug 135604, we should add an option to disable the javadoc attachment per project. This would allow the user (behind a firewall for example) to disable the javadoc retrieval without editing manually each classpath container entry or classpath entry. Editing each entry to remove the javadoc attachment makes it painful to add it back if the firewall is disabled. The information has been lost.
Does per project help? Isn't the shared JRE still bound to just one (the first project) when asking for its parent? Also, if I'm disconnected, do I really need/want to go into each project?
I think it rather should disable the attempt to resolve an external java location. Local locations ('file://...') can still be used, everything else skipped.
Ok, good point. Then change the title.
Created attachment 39192 [details] Proposed fix Frederic, Could you please review it to see if I didn't miss anything in adding a new option? Thanks.
Sounds OK for me
Re: comment 2. I don't think "file:" is a valid criteria for determining local/external. It could denote a mounted file on the filesystem, which can be unavailable when disconnected. I would rather favour a global solution (all or nothing).
Mike ? Would you cast a vote for this feature addition ? (a pref addition for controlling retrieval of javadoc for fault-tolerance). Basically, without a pref, user has no choice by edit all his .classpath files to remove javadoc locations (and add them back once re-connected).
Created attachment 39287 [details] Proposed fix New patch disables the javadoc attachments in all cases. Not just for http protocol.
Frederic, Could you please review it? Thanks.
Adding a preference for this is fine. +1. I took a look at the patch and it does not appear to include the GUI for changing the value. I'm assuming you will want to do that. Given how unlikely it is that most people will want to change this setting, you will need to make sure that adding support for it does not make the commonly used JDT preference pages even more complex.
Added bug 138202 for the UI conterpart.
+1 for 3.2RC2
Fixed and released in HEAD.
(added API constant JavaCore#ENABLE_JAVADOC_ATTACHMENTS)
Sorry if I'm really late now, but the Zurich lab was offline the whole afternoon due to a holidays and our IT department being on holiday as well so the internet was down and not fixed. I have to request changes to the constant name and spec: - 'ENABLE_JAVADOC_ATTACHMENTS' -> 'ENABLE_JAVADOC_ATTACHMENTS_ACCESSES' As you say, Javadoc attributes are still there, just not used. - 'When disabled, javadoc attachments are not used to retrieve the javadoc of java elements.' -> 'When disabled, javadoc attachments are not used to retrieve the javadoc of java elements in IJavaElement.getAttachedJavadoc and for parameter names for elements with missing source' In JDT we use the javadoc location for features like the 'Open External Javadoc', the Javadoc wizard, and for help links. Javadoc wizard and help links are not under our control. We can't promise the user that disabling this option will disable all useages of the Javadoc location.
I don't believe we need: * and for parameter names for elements with missing source Since the getParameterNames() already says: * For binary types, associated source or attached Javadoc are used to retrieve the names. * If none can be retrieved, then these names are invented as "arg"+i, where i starts at 0. * Returns an empty array if this method has no parameters. I'll change the field name, but I propose: * When disabled, javadoc attachments are not used to retrieve * the javadoc of java elements in {@link IJavaElement#getAttachedJavadoc(IProgressMonitor) IJavaElement.getAttachedJavadoc}. for the doc part.
Daniel, Right now the current behavior is far from being ideal for the user when behind a firewall. I don't get an unresponsive UI anymore, but there is absolutely no feedback to the user that indicates why the doc cannot be displayed. If this is OK, I will remove the new preference and keep the actual behavior.
>I don't get an unresponsive UI anymore, Good. I think the unresponsive UI was the trigger for the bugs and this preference. Platform Text fixed that bug as you just confirm here. >but there is absolutely no feedback to the user that indicates why the doc >cannot be displayed. The preference would affect this scenrio only after enabled. Until then - even with the preference in place - the user will not get the feedback and will not know about this preference. And I doubt that anyone is going to toggle that preference when going on/offline. Regarding "having no clue" - this is a valid point. According to the spec you throw a JME in case of timeout. If we'd have a way to recognize the timeout we could show this in the hover. But that's post 3.2.
Then I reopen to revert my changes and close as INVALID. It would have been nice to be aware of changes from JDT/Text in this area.
+1 for removal
>It would have been nice to be aware of changes from JDT/Text in this area. My very first comment to the initial bug 129168 was mentioning the bug in JDT Text land and marking it as blocking the JCore bug i.e. unless you manually tweaked bugzilla mail preference you did get a notification that the JDT Text bug got fixed.
Removed. Fixed and released in HEAD.
