Re: [cross-project-issues-dev] HTMLPrinter is Broken

Leo, I have read the whole thread. Comments below. On 25.01.2018 17:44, Leo Ufimtsev wrote: I haven't read the whole thread. But I think it's fairly common sense that one should not use internal api by an external project. It's just one of life's axioms. It's definitely best avoided, when

Re: [cross-project-issues-dev] HTMLPrinter is Broken

I haven't read the whole thread. But I think it's fairly common sense that one should not use internal api by an external project. It's just one of life's axioms. It's like people who use reflection to get to private members of a java class and deploy that code into production. That's just a

Re: [cross-project-issues-dev] HTMLPrinter is Broken

> I say that, as long as existing internals can be used, they are de facto API. That is incorrect and the current meaning is well defined. See x-internal description in the help https://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html

Re: [cross-project-issues-dev] HTMLPrinter is Broken

Ed, My answers below > I think that this is the path paved with good intentions. Sure it is. I wish for the peace in world (even if it is the road to Hell) :) > We'll need to start at the bottom, in the Equinox runtime. For example, > we'll need to change a great many things in p2 before PDE

Re: [cross-project-issues-dev] HTMLPrinter is Broken

> Le 25 janv. 2018 à 10:22, Lars Vogel a écrit : > > > Should we change our policy and stop exporting new internal packages so > > that they really cannot be used? > > -2, we want to enable extenders to use and explore code before making it API. > IMHO a good way to

Re: [cross-project-issues-dev] HTMLPrinter is Broken

Hi For 'stable' projects such as JDT deprecating+hiding/promoting internal may make sense, but it probably hides the code so that users in missding the opportunity to abuse users also miss the opportunity to exploit in other ways. For 'evolving' projects such as Xtext, internal has provided

Re: [cross-project-issues-dev] HTMLPrinter is Broken

> Should we change our policy and stop exporting new internal packages so that they really cannot be used? -2, we want to enable extenders to use and explore code before making it API. IMHO a good way to provide new API is by having it already been explored by users. > And for existing internal

Re: [cross-project-issues-dev] HTMLPrinter is Broken

Mikaël, I think that this is the path paved with good intentions. We'll need to start at the bottom, in the Equinox runtime.  For example, we'll need to change a *great many *things in p2 before PDE works again; we'll also need to change many things in p2 so that Oomph works again, we'll

Re: [cross-project-issues-dev] HTMLPrinter is Broken

Very interesting thread, thanks to all for sharing your opinion. Changing existing internals could break clients because so far, they can use it. Should we change our policy and stop exporting new internal packages so that they really cannot be used? And for existing internal that one wants to

Re: [cross-project-issues-dev] HTMLPrinter is Broken

Leo, While I agree in principle, the principles lead down a path where I'm sure no one really wants to go; it is the path paved with good intentions. Specific comments below. On 24.01.2018 18:24, Leo Ufimtsev wrote: Hello Ed, On Wed, Jan 24, 2018 at 7:27 AM, Ed Merks

Re: [cross-project-issues-dev] HTMLPrinter is Broken

Hello Ed, On Wed, Jan 24, 2018 at 7:27 AM, Ed Merks 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) > > I understand your frustration, we sometimes

Re: [cross-project-issues-dev] HTMLPrinter is Broken

Mickael, Comments below. On 24.01.2018 15:08, Mickael Istria wrote: Hi Ed, all @Ed: First, don't pretend you don't know what "internal" means here, you're smarter than that. Those projects deliberately built against such risk and it's fair to have them dealing with there own issues.

Re: [cross-project-issues-dev] HTMLPrinter is Broken

Ed Merks <ed.me...@gmail.com> >> To: cross-project-issues-dev@eclipse.org >> Date:24.01.2018 14:31 >> Subject:Re: [cross-project-issues-dev] HTMLPrinter is Broken >> Sent by:cross-project-issues-dev-boun...@eclipse.org >>

Re: [cross-project-issues-dev] HTMLPrinter is Broken

Your not a jerk Ed ;-) I suggest you open a bug to add your bundles as friends. That way we can notify you upfront. Dani From: Ed Merks <ed.me...@gmail.com> To: cross-project-issues-dev@eclipse.org Date: 24.01.2018 14:31 Subject: Re: [cross-project-issues-dev] HTMLP

Re: [cross-project-issues-dev] HTMLPrinter is Broken

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

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.

Re: [cross-project-issues-dev] HTMLPrinter is Broken

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

Re: [cross-project-issues-dev] HTMLPrinter is Broken

On Wed, Jan 24, 2018 at 2:27 PM, Ed Merks 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