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
<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
really a very small problem that's easy to avoid, and I appreciate his
effort and his explanation about Sonar warnings, which I did not take
into account. This is give an take. I change the EMF templates so that
they generate StringBuilder instead of StringBuffer so that Lars can
regenerate the platform UI models. And he's kind enough not to take
offense even when I'm a jerk; lack of sleep tends to cause that.
Now, for the specific case of HTMLPrinter, I agree it would better
become an API then.
@Ed: would you mind opening the bug request?
_______________________________________________
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
_______________________________________________
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
