The code in
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)
User: Marek Fukala <email@example.com>
Log: #173989 - Copy pasted RunOffAWT code