[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] HTMLPrinter is Broken
|
Hi
I have to agree that internal is internal and if really necessary can be
changed with complete disregard to users.
For similar usage scenarios, I create a "ripoffs" package. e.g.
http://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.xtext.base.ui/src/org/eclipse/ocl/xtext/base/ui/ripoffs
Far from perfect but transitively everything used is project or public
API and so there should be a couple of years warning once a revision is
needed and there is a project API that can be revised. Unfortunately the
"ripoff" lags behind on bug fixes.
If there was regular way of registering the "ripoffs", it might provide
some motivation for some enthusiast to refactor useful internals into
public utilities. Today we can raise an enhancement Bugzilla which will
understandably vanish into the "helpwanted" long grass. Multiple
arbitrary requests will only converge if re-users are motivated to
register and committers are observant in their "duplicates". Perhaps an
agreement that a "ripoff" Bugzilla is titled e.g. "Expose
org.eclipse.jface.internal.text.html.HTMLPrinter.java" so that the
multiple re-users can vote and/or add their +1's.
Regards
Ed Willink
On 24/01/2018 12:38, Aleksandar Kurtakov wrote:
On Wed, Jan 24, 2018 at 2:27 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:
I'm a more than little annoyed to see that this method
org.eclipse.jface.internal.text.html.HTMLPrinter.insertPageProlog(StringBuffer,
int, RGB, RGB, String)
has gone from deprecated to deleted in less than a 5 week period:
https://github.com/eclipse/eclipse.platform.text/commits/master/org.eclipse.jface.text/src/org/eclipse/jface/internal/text/html/HTMLPrinter.java
JDT, EMF, Xtext, and Oomph all use this method.
So where were the people from these projects all these years and no
one have stepped in to make such a thing proper API?
I really don't care to hear the arguments about it being internal because:
I don't see that JDT ought to have exclusive special privileges to use
internal things.
I don't see any reason why it should be internal.
And any client wanting to implement hovers that work like the ones for JDT,
will have the same needs as JDT and will solve the problem the same way.
I'd like to avoid dwelling on the fact that this is simply a pointless
change, but I can't help it. Surely one wouldn't change this simply to
improve performance in code that has no relevant performance impact! It
seems to me at best a misguided effort that would be better spent on real
improvements.
Neither you nor me nor anyone else has the right to tell anyone what
to contribute in his own time!
Please revert this change before M5.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=530240
And in the future, please consider that any internal API that is used by any
other project is going to cause problems for many projects just as it did
for JDT:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=529118
You're not serious, right? Do you seriously expect for every change to
do a check on every Eclipse plugin existing whether it used the
internal method to be changed? Oh wait that can't be only the release
train this must include Pydev, JBoss Tools , Spring Tools and etc,
right?
If anyone has such expectations this is clearly not going to happen.
For every case where someone uses internal he/she must know it's a
risk taken by them on purpose.
I for one strongly disagree with exporting internal packages from
bundles at all, that would solve so many such issues and boost people
to work in proper way!
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
