Community
Participate
Working Groups
Build Identifier: 20110301-1815 When creating an annotation through the "New > Annotation" mechanism, a developer must always manually add the desired @Retention and @Target annotations in the text editor after the initial code is generated. Code completion can help this, but it could be done more simply (from the user's perspective) by having radio buttons (for @Retention) and checkboxes (for @Target) in the New Annotation dialog. Reproducible: Always Steps to Reproduce: 1. Right-click a Java package or source folder. 2. In the context menu, select New, then Annotation. 3. No Retention or Target controls are present.
Yes, that would make sense. We should also add a checkbox for @Documented.
I am currently working on this feature.
New Gerrit change created: https://git.eclipse.org/r/67561
*** Bug 160343 has been marked as a duplicate of this bug. ***
Harald, this should be delivered with M7 for Neon, or should be postponed to 4.7.
@Noopur Thanks for the reminder. I'd very, very much love to work more on the issue but it's impossble at the moment. I just uploaded patch set #9, which IMHO is ready for review. I skipped stripping of HTML from the tooltips for now because I'd love to hear your opinions on the code in general first. The javadoc tooltips drive me crazy: If the javadoc can be harvested from local files (project uses a JDK), things are easy. There is very little HTML to strip, and the strategy used in org.eclipse.jdt.internal.ui.util.JavadocHelpContext.retrieveText(IJavaElement) works well: strip HTML, return first sentence. Probably regexes would do the job as well But if no local javadoc exists (project based on JRE), it will be fetched from internet resources. There are two issues associated with this: * formatting of the online resources is very much richer. The above mentioned strategy will only return the field name in caps. Real parsing is required. * the connection might be blocked by a firewall, which causes latency My preferred solution is to disable remote fetching of javadocs, but I can't see a way to to that.
(In reply to Harald Albers from comment #6) > @Noopur Thanks for the reminder. I'd very, very much love to work more on > the issue but it's impossble at the moment. > > I just uploaded patch set #9, which IMHO is ready for review. > I skipped stripping of HTML from the tooltips for now because I'd love to > hear your opinions on the code in general first. Code looks good. See Gerrit comment for pending issues (along with updating code for Javadoc tooltips). > The javadoc tooltips drive me crazy: > If the javadoc can be harvested from local files (project uses a JDK), > things are easy. There is very little HTML to strip, and the strategy used > in > org.eclipse.jdt.internal.ui.util.JavadocHelpContext.retrieveText(IJavaElement) > works well: strip HTML, return first sentence. Probably regexes would do the > job as well It is not required to extract the first sentence after converting HTML to text. The text in additional tags may also be useful in the tooltip. With this approach, the Javadoc for a project using JRE will also have all the required information. > But if no local javadoc exists (project based on JRE), it will be fetched > from internet resources. There are two issues associated with this: > > * formatting of the online resources is very much richer. The above > mentioned strategy will only return the field name in caps. Real parsing is > required. > * the connection might be blocked by a firewall, which causes latency > > My preferred solution is to disable remote fetching of javadocs, but I can't > see a way to to that. Markus, is there a way to disable that?
There's another issue with remote fetching of javadocs in this context: The docs are fetched directly, ignoring the proxy settings.
* Getting the Javadoc hovers right will be a huge time sink. We cannot fetch Javadocs in the UI thread, and the content from the Javadoc attachments includes header infos that cannot just go into a plain text hover. The right solution would be to extract JavadocHover.HoverControlCreator and write a new subclass of AbstractHoverInformationControlManager that works on arbitrary controls. There, we already have all the necessary infrastructure to fetch hover infos in the background and to present them nicely formatted. Let's drop the Javadoc support for now. We can add a link to the online Javadocs to the help in /org.eclipse.jdt.doc.user/reference/ref-wizard-annotation.htm . * Mnemonic conflict: @&Target vs. pro&tected. Solution: @T&arget * Patch set 13 doesn't work when I select an enclosing type. #constructCUContent(..) is not called in that case. Furthermore, it's unsafe to just add simple names to the buffer and then hope that the result from ImportsManager#addImport(String) is a simple name. You should compute the source in createTypeMembers(..) and thereby use the result from addImport(..) to create type references. I don't see a very clean way to prepend the annotations there, but directly accessing the CU buffer like this should do the job: int start= newType.getSourceRange().getOffset(); newType.getCompilationUnit().getBuffer().replace(start, 0, "@Xyz ");
(In reply to Markus Keller from comment #9) Thanks, Markus. I missed the 'Enclosing type' checkbox while reviewing the patch.
Thanks for the review, Markus. Your comments about code generation were very helpful. I've had a look at IType before, but as it does not support adding annotations (directly), I went for alternatives. With your help, the solution is much cleaner. And it works in all contexts. Pushed Patch set 15 which addresses your comments.
Gerrit change https://git.eclipse.org/r/67561 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=ae0f4733850d80765bd9b59df53774626d27df6d
Thanks for the updated patch, Harald. It has been committed to the master branch.
(In reply to Noopur Gupta from comment #13) > Thanks for the updated patch, Harald. It has been committed to the master > branch. Thanks, Noopur. I'm looking forward to Neon to see this in action!
