Thursday, June 12, 2014

Last month (May) in Red Hat Eclipse

May is not the most exciting month in terms of Eclipse development - it's all about final touches, release procedures and handing these bits to the users. With the previous said it might actually be the most exciting from users point of view.
The team spent a lot of time on getting things from Luna release train built and available in Fedora Rawhide (future Fedora 21 release) - Platform, CDT, Linux Tools, Mylyn and their dependencies are available to Rawhide users now.

Here is the detailed report:
P2
  • P2 - Use runnable repo to collect metadata (commit)
  • P2 - Propose improvements to fragments generation (review)
SWT
  • Review, approve, push stabilizing patches (bugs 1, 2, 3, 4, 5)
CDT
PTP Remote
  • Drop circular dependency with CDT (commit)
Linux Tools
  • GCov coverage bars change to green/red (review)
  • GCov add compile/link flags automatically (review)
  • SystemTap - many cleanups, remote operations improvement, context sensitive UI elements and user guide improvements (git log)
Test and celebrate with us the soon to be available Luna release train.

Wednesday, May 7, 2014

Last month (April) in Red Hat Eclipse

This is post is heavily inspired by Last month (April) in Red Hat KDE . Great idea which I dare to copy almost entirely ;)

So here is the Red Hat Eclipse one (limited to eclipse.org projects work):

Equinox

  • add build support for GTK/Linux/PPC64LE launchers (commits 1, 2)
  • remove build support for motif launchers (commit)
  • simplified launchers maven build (commit)

SWT

  • add build support for GTK/Linux/PPC64LE fragment (commits 1, 2)
  • fix FontDialog crash with GTK 3.10 (commit)
  • fix PrintDialog crash with GTK 3.10 (commits 1, 2, 3, 4, 5)
  • fix Combo inheriting font from parent (commit)
  • fix Widget.setFont using wrong widget handle (commit)
  • fix Button background problems in jface forms (commit)
  • fix List height calculation  (commit)
  • further progress on Webkit2 support
    • solved deadlock issue by decoupling the synchronicity by executing the JavaScript asynchronously
    • added support for creating unique dbus addresses for each instance of the extension
    • created a function to find resources (mimicking the library loading search in SWT) to load the webkit extension
    • fixed a crash in the WebKit2 port when visiting gmail.com (frames without document object)
    • back ported API for passing information to WebKit extensions during initialization
    • found a workaround for the missing GDBusNodeInfo struct definition in older glib versions

CDT

  • support remote Autotools projects (commit)
  • fix Autotools projects to support user defined make (commit
  • GDBStandaloneDebugger have seen final touches to make it a proper product. Details.

Linux Tools

  • API/Javadoc cleanup in preparaton for 3.0 release (many commits)
  • Libhover ported to not use swing.html for parsing (commit)
  • Libhover supports gtk-doc 1.20 generated docs (commit)
  • GCov opens full featured editor from CDT instead of its own(commits 1,2)
  • SystemTap plugin have seen polishing changes to get smoother experience (commits)
Brought to you by: Jeff Johnston, Roland Grunberg, Sami Wagiaalla, Andrew Ferrazzutti and Alexander Kurtakov.


You can find us on #eclipse-linux and #fedora-java channels on Freenode IRC.


Tuesday, February 25, 2014

Thoughts on Eclipse platform

Many people complain about how the Eclipse platform is not helping building a community but there are some other thoughts that I can't get rid of.
People want to drive "big" changes from the beginning but in reality it doesn't work that way in no FOSS project - one has to start with small things, not so small, slightly bigger, big, bigger, huge, etc. People that are dedicated go through the process and gain the ability to change so much for the reason that there is not that many other people working on the platform.
Is this perfect - NO, not at all. How can it change? There is only a single way I see - more people start contributing - but not contributing the next big thing - help us revive the platform. Things like:
  • improve test suite - no big change can happen if the committer is not at least partly sure that nothing bad happens. That's a huge opportunity for people wanting to join as it doesn't require that much deep knowledge from the beginning. E.g. in SWT it was a test infrastructure work (~100 commits) just to modernize to the state where there is one test suite for all platforms with all the quirks in it to make it possible to run from maven build in a sane way. And tests can be run from the maven build run but still fail!!!
  • bug triaging - Yes, having 1142(at the time of writing) open bugs for SWT/GTK only is not helping me see new problems. Verifying bugs, producing snippets that make it easier to reproduce, patches that fix it or simply closing the bug cause it has been fixed long ago. This is really valuable help as it is huge time drain. Reports that are vague or too big don't get that much attention as the current amount of people is already having problems driving the next release!!!
  • cleanup the codebase - Making use of new features available for years, standardizing on given idioms, removing deprecated. All these boring things that make it easier to not be afraid of change, to jump into the project easily, to verify things easily, etc.
  • improve the build system - Huge task and huge time drain for potential contributors. If the build takes so much longer than needed even without running the tests in it, how can someone easily verify a change. Yes, I mean building the whole platform and running all tests to verify that you're not breaking something few layers above you.

If/when we get the things above done - jumping into the problem space would be way easier and there would be enough people with experience in it already so we don't get to this state again.
With so many Eclipse users and people unhappy with the current state of affairs maybe it's time to try different approach. Is this the right one? No idea. Will it work? No idea either, but there is only one way to know it - let's try.
This is plea to the people that haven't been involved into Eclipse and wondered whether they can help improve - Yes, you can.


P.S. These are my own thoughts and doesn't represent a statement from any of the Eclipse groups I'm member of.

Tuesday, November 26, 2013

Eclipse platform developer needed

We are hiring!

If you are interested to work on:
  • Eclipse Platform - UI, SWT, P2,...
  • Eclipse Releng - upstream (CBI) and Red Hat (RPM) 
  • Simultaneous Release train - Mylyn, EGit/JGit, ....
  • Integrating Eclipse and Linux ecosystems
  • And other interesting projects
 ... we have a position right for you - send your application here.


Saturday, October 26, 2013

GTK 3 backend becomes SWT default

GIT commit - I've been waiting for this becoming true for so long.

Join us testing, reporting and sending patches that improve the situation. This should appear in the soon to be re released 4.4 M3.

Thursday, September 19, 2013

Full featured IDE in your browser and Eclipse

We all hear about the new and cool web IDEs - I looked at few of them and somehow all looked too poor for someone used to do pretty much in his IDE (that's why we have I-ntegrated in the name, right?). So I decided to take another look at the problem from different POV and here it is:





That's Anjuta running using GDK Broadway backend, sample C project created, compiled and launched(the empty window on the right) - all in the browser.
Simple instructions that work on Fedora 19:

  • 1st terminal - start broadwayd 
  • 2nd terminal - GDK_BACKEND=broadway anjuta
  • browser - http://localhost:8080
Isn't that cool?
As an Eclipse user and developer I wanted to immediately see my Eclipse working on my development machine and being able to use it from various connected devices at home for small things like - launch hudson build via mylyn builds, comment on bug via mylyn tasks, pull from Gerrit for a quick review and etc. all via plain old http while having my setup working and no vnc or alike solutions needed (that take more time to get on your phone than few web clicks). To be honest I didn't expected it to work but this doesn't mean I have to stop dreaming. 
Broadway GDK backend is GTK 3.x feature so one first need to run eclipse on GTK 3. That's easy - `SWT_GTK3=1 eclipse` and you have it. But there is one more prerequisite to use different GDK backends - your app should not do direct X calls and here we fail - eclipse simply crashes because of the direct X calls done if one tries `GDK_BACKEND=broadway SWT_GTK3=1 eclipse`.
Allowing using different GDK backend is important for Eclipse (at least on Linux) as elliminating or changing X calls is needed to also make Eclipse run as native wayland client. The future will catch Eclipse sooner or later.
If you do want to see such future for Eclipse please test Eclipse on GTK 3.x, report bugs, help us fix the issues, provide patches and spread the word about such possibilities so more people can potentially join the fun. Also feel free to contact me directly for anything related and help my dream come true.

Sunday, April 14, 2013

Javac and backward compatibility

It's a nice start of the week to read this. As a Linux distro guy this makes me really happy as it's a first step in the right direction to fix some of the long standing problems for "source-first" developers. Java programs are full of references to libraries that have been cool and state of the art ~10 years ago but it's time to let them R.I.P. 
Dropped support for old targets in javac will hopefully have the nice side effect to reducing the private patched jars many projects has in their scms. (Please stop including activation.jar with your app!)
Not to mention that it will help moving to newer JVMs - yes, I'm looking for the moment noone will ask me to compile my projects to target 1.5 as it would be just impossible. The answer would be awesome - javac don't support it anymore!
Sometimes I even wish to see something like "one plus FIVE back" for the JVM itself - aka Java 9 stop loading bytecode from pre-1.4 times. This would lead  to huge cleanup in resources used by applications by making people look forward as now it's impossible to have a coherent support for even 2 application with the same set of libraries as each of them has stalled some dependency in the very distant past to the state it becomes impossible to collaborate. And NO, shipping private copies is not OK - search for the jakarta-httpclient CVEs which would not be fixed as it is EOLed and no further releases will happen(rightfully as it has been EOLed for years already!) but many applications expose their users by shipping a private copy most of the time not even knowing.
Even if this has been standing in my mind for quite some time I never expressed it in non-private conversation and reading that there is a hope made me start the week with some joy :).