Simon,
Comments below.
On 12/07/2015 12:26 PM, Simon Schäfer
wrote:
On 07/07/2015 09:22 AM, Sebastian
Zarnekow wrote:
Hi Simon,
after all Eclipse is Open Source - you cannot expect other to
step up and do exactly what you need essentially for free.
Yes, since the very beginning most of its code is written in
Scala. But that is not the only problem. The release cycles of
Eclipse are also suboptimal. Since we don't release our own
plugins at the same time when Eclipse ships a new major version,
we couldn't easily integrate any new features that go to the
platform in our own releases.
The train does release three times per year, but two of them are
"just" service releases. That being said, a number of projects do
minor a minor release for each train release, including for the
platform's service releases. Of course no matter the cycle, you'll
only want to release your projects based on releases of other
projects.
I know but I don't expect that anyone looks at these problems,
therefore there is no point in wasting time writing even more
text.
This is all just very negative. If you don't expect anyone to look
at it, there's not even any point in wasting time complaining about
it. What kind of result are you expecting from saying that people
took all the rules for how to do something well just so they could
do the opposite?
This is difficult to explain. Very often I have the feeling (when
I look at an interface and at its corresponding implementations
that are shipped with the platform) that the interfaces are just
extracted from the implementation. I can even remember that I saw
classes that took an interface as a dependency in their
constructors and immediately downcasted it to a concrete
implementation (without any instanceof checking). Generally, such
components can't be reused in any way.
I don't understand the point of the Eclipse Foundation. They pay
bills
Yes, but what kind of bills? Bills to pay for staff that manage the
operations of the organization, e.g., IT staff to keep the website
running.
but refuse to lead further development of the
platform or at least pretend further design choices.
That definitely is not the role of the foundation. They don't tell
me how to develop my projects, nor do they pay me to develop my
projects.
But now there is no point anymore in whining - that
comes 10 years too late. Developers lost trust in the platform and
they are leaving together with their users.
It sounds like you've done a market survey.
I doubt it, really.
This discussion seems pointless then.
Internal issues can't easily be fixed especially
because the people who wrote most of the code don't see its
limitations.
I can't comment on what can be easily fixed or not, but I certainly
know that issues I've reported are being fixed and contributions
I've made are being accepted.
Furthermore, the Eclipse Foundation showed in the
last years that they have no further interest in the IDE part of
Eclipse, which is the only thing I'm interested in.
I've been a member of the Eclipse Board of Directors and know for a
fact that what you're saying here is simply false.
I don't know if any of this RCP stuff is successful,
at least it is of no use to me and I doubt it is useful to anyone
else who wants to write an IDE.
You're referring to the e4 effort... I have to agree that this, if
anything, has resulted primarily to regressions in quality and
performance in terms of the IDE functionality.
I can hardly see any improvements to the IDE
functionality since 4.0. The only thing that comes to mind is a
GUI improvement: Quick Access (the improvements of 4.0 were not
even needed to implement this one). Except, everything in it is
hardcoded, you can not even add your own entries that are not in
one of the ~6 predefined categories.
The first thing that needs to be done before any technical
problems can be addressed is to raise awareness to the Eclipse
core contributors that all of their features may be used by every
plugin out there. In my opinion Quick Access shows a lot of what
is wrong with Eclipse: Dump implementations, too many people with
write permissions to the main branches, no or bad code reviews,
new features are forced to everyone (instead of making them the
default but optional) and of course no awareness that others may
have other interests+needs.
Only direct involvement can make your needs know. But I'll warn
you, when you talk about "dump implementations", "bad code reviews",
and "reversing all the good Java programming rules", people will
quickly become deaf to all you have to say.
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev
|