date:20180124

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

2018-01-24 Thread Ed Merks


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 > 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 have to deal with similar 
problems.
E.g when Gtk makes changes to their methods, it breaks SWT and causes 
glitches in Eclipse.


But:

As the package suggests, it's an /internal/ method: 
org.eclipse.jface./_*internal*_/.text.html.

'Internal' means it's not suppose to be used by public.
Yes, the point of "internal" has been hammered upon, but it's a general 
point, like human rights, and of course we all agree the humans should 
have plenty of those.  But it strays far and wide from the specific 
problem at hand.  The irony of the specific problem is apparent is when 
you look at the call hierarchy of the methods in question. They're not 
used internally at all, unless JDT is considered internal, which it 
clearly is not.  As a result of JDT's trending setting example, you'll 
find uses of this in any code that tries to have really nice hover 
information like JDT does. Given there bugs are open asking for it to be 
API, it's clear there are clients of this specific code.  Yes, they're 
all bad, very bad.


Of course I empathize with Lars' efforts to make improvements, and I 
have in fact helped him in part with those changes, so I more than 
resent arguments that I personally stand in the way of the platform's 
great progress.  Of course I could have been less of a jerk in how I 
phrased my opinion on this specific change.  Sorry for that.


If you wish to use internal api because it's useful to you, then you 
should first put in effort to make
the api public and /only then/ use it. Not use it and then complain 
about it's removal.
Yes, the human rights issue again.  The Bugzilla record speaks for 
itself though as does the call hierarchy of the methods, which makes it 
clear they exist to be used outside of the project that provides them.  
Had this high standard been applied to JDT, we'd not have this problem.  
There simple is a double standard.  Had we applied this standard when 
developing Oomph, there would be no Oomph.  So while it's a high and 
mighty principle that one cannot argue against without the wrath of the 
human rights activists protesting at your door, it's simply not 
pragmatic and has not been well applied by the overall Eclipse PMC itself.


And again, the specifics of the problem StringBuffer -> StringBuilder; 
of course a trivial change, one that I can change in two minutes in EMF, 
but not without maintaining my compatible version ranges in EMF.


Because you chose to use internal api, and your suggestion to revert 
the code removal, you are slowing down platform
development and by extension slowing down the whole Eclipse 
development process.
Yes, I see it's a significant human rights violation.  But I thought I 
did my part for human rights when I changed EMF's templates to generate 
StringBuilder in places such as the generated toString() method of each 
EClass.


I know JDT, Dani and his team,  are very careful with changing internals 
because they know many clients use them, and they know that while making 
rapid progress is great, if they behave disruptively because they have 
the intrinsic right to so so, they could end up with fewer clients.  And 
kudos to Dani and his team for their consideration; EMF uses JDT 
internals as well and has never in 15 years been broken by any JDT 
internal "API" changes, even with the changes for Java 9.  It's an 
impressive accomplishment for the JDT team, and I'm sure that as a whole 
it slows them down, but they carefully consider the overall balance.


It's very important for us to stay agile and move quickly, this 
involves being able to refactor old code, remove redundant code etc..
It's not so clear to outsiders in which direction things are moving 
quickly. I don't think StringBuffer -> StringBuilder is arguably a case 
in point.  No one actually cares whether a toString method uses 
StringBuilder as opposed to StringBuffer, but of course that can be 
easily changed because no one can see that change.  But changing the 
signature of visible methods begs for more caution and consideration, 
especially when these internals are in fact only used externally.


As case in point, in Fedora, "yum" got dropped and replaced with 'dnf' 
package manager
because "yum" had too much internal api being used by external users 
and they couldn't refactor/stay agile.


My experience with HTMLPrinter is that it took me longer than 
necessary to fix some color related issues
in platform because HTML

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

2018-01-24 Thread Daniel Megert

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 
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



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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM=50p2gyLnZ2yrTvMNr-EHOj763JbrtI5g1fEXaARApNA=
.
>
> Best regards, Lars
>
> On Wed, Jan 24, 2018 at 1:38 PM, Aleksandar Kurtakov
>  wrote:
>> 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 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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM=KoFeo7tub-Xb3i3EYnBMplV0XenejhYu64vZ-D8ALa4=

>>>
>>> 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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM=50p2gyLnZ2yrTvMNr-EHOj763JbrtI5g1fEXaARApNA=

>>>
>>> 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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM=FJrHvo6JhTfeqSgyEN-FUq2UHlAsAv2yjwQuu80nTgw=

>> 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@eclipse.org
>>> 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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM=iC7HtTQ11TU_s80zmRghvNAqsWbgewGnDdruNlXB_o0=

>>
>>
>> --
>> Alexander Kurtakov
>> Red Hat Eclipse Team
>> ___
>> cross-project-issues-dev

[cross-project-issues-dev] EMF GWT

2018-01-24 Thread Ed Merks

I'm considering dropping support for EMF's GWT components from EMF 
2.14.   If you don't care, don't read any further because I'll interpret 
silence as not caring.


The problem is that I'm still using very old versions of GWT and 
AppEngine tools.  These tools are broken in the latest Oxygen release 
because of methods removed by JDT:


java.lang.NoSuchMethodError: 
org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots([Lorg/eclipse/jdt/core/IClasspathEntry;ZLjava/util/Map;)[Lorg/eclipse/jdt/core/IPackageFragmentRoot;
    at 
com.google.gdt.eclipse.core.ClasspathUtilities.findRawClasspathEntryFor(ClasspathUtilities.java:163)
    at 
com.google.gwt.eclipse.core.runtime.GWTRuntime$ProjectBoundSdk.findGwtDevClasspathEntry(GWTRuntime.java:369)
    at 
com.google.gwt.eclipse.core.runtime.GWTRuntime$ProjectBoundSdk.computeInstallPath(GWTRuntime.java:269)
    at 
com.google.gwt.eclipse.core.runtime.GWTRuntime$ProjectBoundSdk.getInstallationPath(GWTRuntime.java:190)
    at 
com.google.gwt.eclipse.core.runtime.GWTRuntime.findSdkFor(GWTRuntime.java:421)
    at 
com.google.gwt.eclipse.core.validators.GWTProjectValidator.build(GWTProjectValidator.java:77)
    at 
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)

    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
    at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
    at 
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)

    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
    at 
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
    at 
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
    at 
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142)
    at 
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232)

    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)

So I can no longer use a development environment newer than Neon to work 
on them.


Also the tools have been migrated to new versions hosted at other 
locations.  I think I could get most of this working with the latest 
tools, but org.eclipse.emf.server.ecore.resource.DatastoreUtil uses 
com.google.appengine and the tool for that now requires one to install a 
Cloud SDK separately rather than embedding an SDK (or whatever is needed 
at compile time) in the Eclipse bundle. Setting up such a development 
environment is a PITA and also doing so for the Tycho build is a second 
PITA.


Does anyone care?

Regards,
Ed

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

2018-01-24 Thread Ed Merks


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. 
Platform is a welcoming project, and anyone who needs to make code API 
can ask and do.

That's great in principle, but often not so workable in practice.

What you fail to take into consideration is that EMF tries to provide 
the broadest range of environments into which EMF can be installed.  So 
the best I could do in this situation is to change my code to use 
reflection that detects which versions of the methods are available.  
And even if new APIs were introduced in Photon, I'd still end up with 
yet more ugly reflective code to cover all the bases.


Oomph is in a similar boat, supporting the ability to create Juno 
installations and running in those installations (thanks to the fact 
that EMF supports that too).  If you saw how much internals we've needed 
to use in Oomph you'd hurl.  If we waiting for APIs, we'd still be 
working on creating them, with nothing to show for it.


In life there are ideals and I think we all agree on what ideally should 
be the case.  And then pragmatism must set in because we need to 
accomplish a goal today, or this year.


 1. I don't see that JDT ought to have exclusive special
privileges to use internal things.

JDT doesn't have privileges and everyone is free to use internal packages.
But JDT succeeds to do it well because it does understand and comply 
with the meaning of internal and have set some practices to not be 
affected in a breaking way: building against Platform master source 
code or latest integration/nightly build to spot defects ASAP, 
agreement in making the necessary changes when need be or asking 
immediately to Platform for some remediation in too tricky scenarios, 
configuration of version range to not be affected by changes in 
internal code...

You'll note that I reported this *problem *before it appeared in M5.
Every project that follows similar practices can safely use internals. 
Projects that use internals without such practices were warned in the 
IDE when choosing to pick and internal API, and deliberately chose to 
ignore the warning either by keeping the reference to internal code, 
or not setting up a process that allows to spot such issues extremely 
early.
We can detect the problem, but as I explained above, it's not always 
possible to simply change StringBuffer to StringBuilder and have the 
problem go away, though that worked nicely with JDT because it doesn't 
expect to be able to install into Oxygen.


Fortunately, the milestone builds are here so that even projects that 
don't have such a process as JDT one can detect issue a bit later, 
during milestones and react accordingly.
Oomph's Targlets use the platform's IBuilds by default for a Photon 
target platform, so that helps find problems early too.


But I agree with Alex and others that any request to have internal 
code managed like API is something Platform cannot afford at the 
moment, and could afford better if users of such internal code were 
more involved in Platform to make those officially APIs, or at the 
very least asking for those to become APIs on the bug tracker.
I've have worked 12+ hour days for the last month getting the darned EMF 
build work, so I can assure you that I do not have a surplus of time to 
invest elsewhere.


Please revert this change before M5.


Why would Platform make an effort for downstream projects not properly 
using code? Platform is fully working as contracted in project plan, 
nothing to blame on Platform here.
Because life a game of give and take and most people realize that. I'll 
point out that I'm not actually personally obligated to provide anything 
for anyone either but I know that getting a build in place is important 
for a great many people so I do it anyway.  We could see how shipping a 
release train works out without the effort I invest in EMF.


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:


Sure, but that won't prevent internal code from changing in a non-API 
compatible way forever. In the future, projects that use internal code 
just have to be ready to change your code which has internal 
references, like they've been expected to be since inception of API 
contracts.

I'm well aware of the facts.


> https://bugs.eclipse.org/bugs/show_bug.cgi?id=529118 



And see how JDT dealt with it? A patch was produced then merged. JDT 
understands what internal means, takes responsibility and remediates 
gently without offending other developers. Take that as an example.
I'll take Lars' changing the code back as a much better example. It's

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

2018-01-24 Thread Lars Vogel

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
 wrote:
> On Wed, Jan 24, 2018 at 4:02 PM, Daniel Megert  
> 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 
>> 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
>> 
>>
>>
>>
>> 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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM=50p2gyLnZ2yrTvMNr-EHOj763JbrtI5g1fEXaARApNA=.
>>>
>>> Best regards, Lars
>>>
>>> On Wed, Jan 24, 2018 at 1:38 PM, Aleksandar Kurtakov
>>>  wrote:
 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 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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM=KoFeo7tub-Xb3i3EYnBMplV0XenejhYu64vZ-D8ALa4=
>
> 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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM=50p2gyLnZ2yrTvMNr-EHOj763JbrtI5g1fEXaARApNA=
>
> 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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=8y3h7LbCTIBhPa94CqhxSgvuij7-UNpSWCKSeHnAxtM=FJrHvo6JhTfeqSgyEN-FUq2UHlAsAv2yjwQuu80nTgw=
 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

Re: [cross-project-issues-dev] EMF and XSD Build Migrated to Tycho

2018-01-24 Thread Mickael Istria

Hi Ed, all,

That's a great improvement for those projects! Thanks Ed and everyone
involved in making this happen!

Cheers,
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

2018-01-24 Thread Leo Ufimtsev

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 have to deal with similar
problems.
E.g when Gtk makes changes to their methods, it breaks SWT and causes
glitches in Eclipse.

But:

As the package suggests, it's an *internal* method: org.eclipse.jface.
*internal*.text.html.
'Internal' means it's not suppose to be used by public.

If you wish to use internal api because it's useful to you, then you should
first put in effort to make
the api public and *only then* use it. Not use it and then complain about
it's removal.

Because you chose to use internal api, and your suggestion to revert the
code removal, you are slowing down platform
development and by extension slowing down the whole Eclipse development
process.

It's very important for us to stay agile and move quickly, this involves
being able to refactor old code, remove redundant code etc..

As case in point, in Fedora, "yum" got dropped and replaced with 'dnf'
package manager
because "yum" had too much internal api being used by external users and
they couldn't refactor/stay agile.

My experience with HTMLPrinter is that it took me longer than necessary to
fix some color related issues
in platform because HTML printer was such a mess of multiple redundant
methods.
I'm actually very glad those methods were removed and I think they should
stay removed.

This is nothing personal. If we move too slowly, eclipse will die and we
will all loose :-(.

Moving forward, I suggest we help each other move fast and keep things
going quickly.
This involves not using internal api and try to make sure platform
development is fast and effective.

Thanks

has gone from deprecated to deleted in less than a 5 week period:
>
> https://github.com/eclipse/eclipse.platform.text/commits/mas
> ter/org.eclipse.jface.text/src/org/eclipse/jface/internal/
> text/html/HTMLPrinter.java
>
> JDT, EMF, Xtext, and Oomph all use this method.
>
> I really don't care to hear the arguments about it being internal because:
>
>1. I don't see that JDT ought to have exclusive special privileges to
>use internal things.
>2. I don't see any reason why it should be internal.
>3. 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.
>
> 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
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

-- 
Leo Ufimtsev, Software Engineer, Red Hat
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

2018-01-24 Thread Aleksandar Kurtakov

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 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@eclipse.org
> 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
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

2018-01-24 Thread Ed Merks


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://bugs.eclipse.org/bugs/show_bug.cgi?id=530240.

Best regards, Lars

On Wed, Jan 24, 2018 at 1:38 PM, Aleksandar Kurtakov
 wrote:

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 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@eclipse.org
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
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev





___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

2018-01-24 Thread Lars Vogel

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://bugs.eclipse.org/bugs/show_bug.cgi?id=530240.

Best regards, Lars

On Wed, Jan 24, 2018 at 1:38 PM, Aleksandar Kurtakov
 wrote:
> 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 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@eclipse.org
>> 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
> cross-project-issues-dev@eclipse.org
> 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: lars.vo...@vogella.com, Web: http://www.vogella.com
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

2018-01-24 Thread Ed Willink

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 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@eclipse.org
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

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

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

[cross-project-issues-dev] EMF GWT

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

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

Re: [cross-project-issues-dev] EMF and XSD Build Migrated to Tycho

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

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

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

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

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

11 matches

Site Navigation

Mail list logo

Footer information