The internal methods are restored via https://bugs.eclipse.org/bugs/show_bug.cgi?id=530240
Ed, please do a quick check, if there is still something missing for you. Best regards, Lars On Wed, Jan 24, 2018 at 3:12 PM, Aleksandar Kurtakov <[email protected]> wrote: > On Wed, Jan 24, 2018 at 4:02 PM, Daniel Megert <[email protected]> > wrote: >> Your not a jerk Ed ;-) >> >> I suggest you open a bug to add your bundles as friends. That way we can >> notify you upfront. > > That is a promise I don't believe we can fullfill. Even if some of us > remember it for HTMLPrinter, this is definetely not a viable path and > I can assure you not many (if any?) will check whether some *internal* > package has x-friends in the manifest registered. > >> >> Dani >> >> >> >> From: Ed Merks <[email protected]> >> To: [email protected] >> Date: 24.01.2018 14:31 >> Subject: Re: [cross-project-issues-dev] HTMLPrinter is Broken >> Sent by: [email protected] >> ________________________________ >> >> >> >> Thanks. I'm sorry for being a jerk. >> >> >> On 24.01.2018 14:02, Lars Vogel wrote: >>> Ed, we have an on-going effort to reduce the number of Sonar warnings >>> in the platform code. Moving from StringBuffer to StringBuilder in >>> our internal API is part of that. >>> >>> As this method seems to be heavily used by others, I'm also surprised >>> that it was never requested as proper public API. >>> >>> As for now I will revert the deletion the "old" internal methods via >>> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D530240&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM&s=50p2gyLnZ2yrTvMNr-EHOj763JbrtI5g1fEXaARApNA&e=. >>> >>> Best regards, Lars >>> >>> On Wed, Jan 24, 2018 at 1:38 PM, Aleksandar Kurtakov >>> <[email protected]> wrote: >>>> On Wed, Jan 24, 2018 at 2:27 PM, Ed Merks <[email protected]> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_eclipse.platform.text_commits_master_org.eclipse.jface.text_src_org_eclipse_jface_internal_text_html_HTMLPrinter.java&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM&s=KoFeo7tub-Xb3i3EYnBMplV0XenejhYu64vZ-D8ALa4&e= >>>>> >>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D530240&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM&s=50p2gyLnZ2yrTvMNr-EHOj763JbrtI5g1fEXaARApNA&e= >>>>> >>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D529118&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM&s=FJrHvo6JhTfeqSgyEN-FUq2UHlAsAv2yjwQuu80nTgw&e= >>>> 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 >>>>> [email protected] >>>>> To change your delivery options, retrieve your password, or unsubscribe >>>>> from >>>>> this list, visit >>>>> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM&s=iC7HtTQ11TU_s80zmRghvNAqsWbgewGnDdruNlXB_o0&e= >>>> >>>> >>>> -- >>>> Alexander Kurtakov >>>> Red Hat Eclipse Team >>>> _______________________________________________ >>>> cross-project-issues-dev mailing list >>>> [email protected] >>>> To change your delivery options, retrieve your password, or unsubscribe >>>> from this list, visit >>>> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM&s=iC7HtTQ11TU_s80zmRghvNAqsWbgewGnDdruNlXB_o0&e= >>> >>> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM&s=iC7HtTQ11TU_s80zmRghvNAqsWbgewGnDdruNlXB_o0&e= >> >> >> >> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > -- > Alexander Kurtakov > Red Hat Eclipse Team > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Eclipse Platform project co-lead CEO vogella GmbH Haindaalwisch 17a, 22395 Hamburg Amtsgericht Hamburg: HRB 127058 Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel USt-IdNr.: DE284122352 Fax (040) 5247 6322, Email: [email protected], Web: http://www.vogella.com _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
