This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The code in http://hg.netbeans.org/main-silver/rev/5b5c28b78bb7 seems to be copy of a code in another part of NetBeans repository. Avoid copy/paste programming and rather invest your time into creation of proper API.
I guess this depends on issue 170882.
This is not a defect in fact since there isn't a generic support for the desired functionality yet. Next time you turn this into defect do not forget to reassign to yourself.
Regardless there is or is not a generic functionality, it is a defect to uselessly duplicate code. You can get rid of such defect by deleting the duplicated code or by helping to create the generic functionality. You cannot get rid of it by turning it into task or anything else that does not appear on the dashboard. Given the fact that 170882 is in progress for 6.8, I do not see a single reason why not keep your code duplication on our bug dashboard radar.
> it is a defect to uselessly duplicate code This assertion is not supported by the bug priority guidelines: http://wiki.netbeans.org/BugPriorityGuidelines In general, only user visible issues are tracked as defects. Need further justification.
Jarda, I am not willing to play a silly ping pong with you so I'll keep the issue in the DEFECT form, but: How can you consider a missing functionality in some of the "core" modules as a defect in the clients? The fact that a code has been copied or created from scratch in a client to overcome a missing platform functionality is a defect? Kidding? Yes, especially, given the fact that the needed functionality is about to be available soon, I want an issue to TRACK the TASK so I do not forget to use it once it is available. What is the point of having 10 defects in several modules just because one "bug" in the platform? BTW, "uselessly" duplicated code? Do you then consider the fix as useless? :-) Have a nice weekend.
fixed in web-main#e214c23f2be9 A funny thing is that the code can hardly be invoked since the java classes hyperlinking is handled by the java hyperlink provider which is bound to the java embedding created at the class position. The only case where it seems to run is when one hovers over the class attribute quotation, in that case another weird thing from user perspective happens - the whole class name including the potential package is marked as hyperlink target in spite of the situation when user hovers the class or packages itself - in that case only the parts of the fqn are marked as hyperlink targets.
Ohh, I should read myself before hitting submit ... to prevent any confusions, I didn't mean the RunOffAWT support, I ment the whole JSP class hyperlinking support.
Integrated into 'main-golden', will be available in build *200911050201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/e214c23f2be9 User: Marek Fukala <mfukala@netbeans.org> Log: #173989 - Copy pasted RunOffAWT code