At the last Eclipse Architecture Council meeting, I said that we, the
Eclipse Project, thought that our ability to deliver the Eclipse SDK R4.2
as part of Juno was at risk. I am happy to say that we have been able to
re-align our development effort, and now expect to deliver Eclipse SDK R4.2
as
Wim,
Can you try and track down where you are seeing the slowness a bit more,
and then open bugs -- if it's not obvious what component, start with
Platform UI? (And put me on the CC)
My experience has been (on both Mac and PC) that the day-to-day development
performance using 4.2 is ok.
-project-issues-dev] Performance, 3.8 versus 4.2
Sent by:cross-project-issues-dev-boun...@eclipse.org
On 09/05/2012 05:12 PM, Mike Wilson wrote:
2) Working through the issues caused by running the performance tests
on shared devices.
[snip]
In a world
The Eclipse Project PMC is looking for community feedback on the use of the
Eclipse SDK on Linux PPC. We believe that the Linux PPC community has
largely moved to 64-bit platforms, and that within the 64-bit world that
"Little Endian" (LE) platforms are becoming the de facto direction.
In an
I agree with Alex's assessment of the perils of using internals. Given the
seriousness of this problem, I would suggest we do a respin anyway, and
would argue we should fix the internal signature at the same time. In
return, the XText team should commit to getting off the use of that method
asap,
The Eclipse Project PMC is looking for community feedback on the use of the
Eclipse SDK on the Windows 32-bit platform. We believe that the Windows
community has largely moved to the 64-bit platform, and this is
particularly true for developers. In addition, after Java 8, Oracle is no
longer
Microsoft support for Windows XP, including security updates, ended in
April 2014 and Windows XP has not been listed as a target environment for
the Eclipse Platform for several years. However, there is still a
significant amount of legacy code in SWT that deals specifically with
Windows XP, to
> I think it's not a good situation to depend on a library which is maintained by a single person/company
> but not accepting contributions with sources excluding tests and no public history of the source code.
>
Agree. For something with obvious security implications, the source code issue is the
Hello cross project people,
The Eclipse Project PMC has approved a change to the target environments for the 2020-09 Eclipse release of the Eclipse Project (that is, our 4.17 release) to be based on Java 11. This will allow us to include Jetty 10, when it is available as indicated here:
