Wednesday, March 13, 2013

All roads lead to Rome

I'm a Fedora Packager. I (amongst others) take care about Eclipse in the Linux world. And one symptom of that care is prodding everyone else to update or drop dependencies. So, if your project suddenly gets a number of bugs open:
  • 398103: adopt latest jsoup
  • 402882: relax requirement on lucene
  • 398102: adopt latest jdom
  • 398100: adopt latest org.apache.commons.lang
  • and so on and so on...
you may be sure it's me. Let's just say that I believe that broad cooperation between open source projects is a must, and staying too long with an outdated dependency is harmful for both, consumer and producer.


Today, I tried to address a bug opened not that long ago:
  • 398084: Adopt rome 1.0
"ROME is a set of RSS and Atom Utilities for Java that is open source under the Apache 2.0 license." to quote their webpage and explain a bit what is this library for.

The said news is that ROME is effectively dead. The last comment from the project author is more than one year old. Project webpage offers 'Related searches'. The source repository does not contain a single tag. Their mailing lists contains spam traffic.

In a normal situation I'd just look for a replacement, but this case is different. There is NO replacement. It looks like a technology shift killed it. There's no need for a new version of RSS or Atom, so project matured and died.

Unmaintained library is a pain. It's a security hole. And will, sooner or later, damage the consumer.  But what to do, if there is no alternative? Hope for the best?

Wednesday, February 27, 2013

A big change in Eclipse P2

One of the problems that have been haunting me since I started work at Red Hat, were changes made to the master configuration. Yes, when you install Eclipse using yum, Eclipse is readonly, and all the configuration changes are stored in your local ~/.eclipse folder.

So, if any change was made to the master installation, equinox was dropping user installed bundles (in majority of cases), but P2 was totally unaware of that change.

In other words - if you installed any feature, it was lost, and you could not reinstall it, because P2 still thought it was installed.

I can't say I was totally unaware of changes happening in P2 regarding those problems, but when I prepared a package of latest Kepler release, I got a dialog:

P2 new feature
Here is the explanation of what happened:
P2 stored a timestamps of important config files during first Kepler launch.
yum changed the installation and touched files
P2 discovered the change and dropped all plugins installed by a user into user space
P2 located previously installed bundles and offered reinstalling them.

I'm sure all devops will appreciate that feature!

May you live in interesting times!

Jetty 9 is around the corner. Well, that's not a news, but a well known fact. Another fact is that Fedora distribution has 'First' in its principles, so it is no wonder that Jetty is already packaged, although still not in a main branch.

As you probably know (maybe from reading this blog), Fedora allows for only one instance of library being installed in the system, and all consumers must use symlinks if they want to consume them. This is also the case of Eclipse. So, if you look at the eclipse installation in the /usr/lib64, you will find:

ls -l eclipse/plugins | grep jetty
-rw-r--r--. 1 root root   21518 Feb 22 16:33 org.eclipse.equinox.http.jetty_3.0.100.v20130222-1445.jar
lrwxrwxrwx. 1 root root      44 Feb 22 16:38 org.eclipse.jetty.continuation_8.1.0.v20120127.jar -> /usr/share/java/jetty/jetty-continuation.jar
lrwxrwxrwx. 1 root root      36 Feb 22 16:38 org.eclipse.jetty.http_8.1.0.v20120127.jar -> /usr/share/java/jetty/jetty-http.jar
lrwxrwxrwx. 1 root root      34 Feb 22 16:38 org.eclipse.jetty.io_8.1.0.v20120127.jar -> /usr/share/java/jetty/jetty-io.jar
lrwxrwxrwx. 1 root root      40 Feb 22 16:38 org.eclipse.jetty.security_8.1.0.v20120127.jar -> /usr/share/java/jetty/jetty-security.jar
lrwxrwxrwx. 1 root root      38 Feb 22 16:38 org.eclipse.jetty.server_8.1.0.v20120127.jar -> /usr/share/java/jetty/jetty-server.jar
lrwxrwxrwx. 1 root root      39 Feb 22 16:38 org.eclipse.jetty.servlet_8.1.0.v20120127.jar -> /usr/share/java/jetty/jetty-servlet.jar
lrwxrwxrwx. 1 root root      36 Feb 22 16:38 org.eclipse.jetty.util_8.1.0.v20120127.jar -> /usr/share/java/jetty/jetty-util.jar

This approach works rather well for many applications, but not necessarily for Eclipse. A simple replacement of Jetty bundles would break Help (I can live without it) and P2 (I can't live without it), so I had to do some little hacking to rebuild the Eclipse with Jetty 9. It works - and probably in Fedora 19 this will be the default setup.
Eclipse Help running in Eclipse with Jetty 9
In a normal situation I'd not even mention such a change - because it's kind of my role to prod everyone to migrate to latest software :-). But this case is very special:
Jetty 9 requires java 1.7.

Eclipse community (especially Platform/RT) is rather conservative in adopting new Java versions. Such an approach has a lot of sense, although... maybe some dates first:
  • 2001: Eclipse Founded by IBM
  • 2002: Java 1.4 released. According to my friend, up to this point it was a perfect language, then they broke it.
  • 2004:  Eclipse Foundation started
  • 2004: Java 1.5 released.
  • 2006: Java 6 released.
  • 2011: Java 7 released.
  • 2013: Java 8 to be released.
Have you noticed the gap between Java 6 and 7? I'd actually dare to say that java 6 was so similar to java 5 that you'd have to count the gap from 2004 to 2011, where Eclipse could just stay one java version behind the main stream.
But things has changed. Java is under heavy development again. Java is being open-sourced. This opens a lot of questions:
  • how long will we have to stay with Java 1.4?
  • is there any plan of migrations when Java will get frequent releases?
  • what to do with features that really require latest Java  (f.e. Jetty)?
It's the question that I have been asked during my interview at Red Hat: what do you prefer and why? Frequent adoptions or staying with "stable" versions and then migrating from one "stable" to the next "stable"?

Interesting times indeed.

Monday, February 18, 2013

Fixing spacing issue in Eclipse in Gnome

Sometimes I run Eclipse on my 13" laptop without an external monitor. This used to be a really problematic, because package explorer/outline were displaying only a few items because of the huge gaps between rows. It was just a pain to me, but nothing really serious. I thought it is intentional and nothing can be done about that. But in the open source world, it is good to be vocal. Someone ( David Mansfield) reported a bug
Bug 910812 - line spacing in tree (specifically in eclipse, e.g. package explorer) is way too large.
and attached following screenshots:
This is how Eclipse used to look like on Linux:
Screenshot of Package Explorer running in a past versions of Fedora.
And this is how it looks like now:
Current appearance of Package Explorer. Note the spacing.
It's arguable which one is better. The latter looks really nice if you run Eclipse on a HD monitor, but it's barely acceptable when using something smaller.

There's solution for that - just set the style of a GTK tree to have no vertical separator - you may use the command attached below:
cat >> ~/.gtkrc.mine << EOF
style "tree" {
  GtkTreeView::vertical-separator = 0
}
class "GtkTreeView" style "tree"
EOF

Eclipse does not look nicer after that, but it's a way more ergonomic, isn't it?

Happy hacking!

Wednesday, January 30, 2013

Installing Counter Strike on Fedora 18 in 4 steps. And some comments.

(1) Follow the instructions listed on this blog to install Steam. Don't worry, it works well on Fedora 18, too.

(1a) If you wonder who is 'Spot', the Fedora 18 unofficial steam package provider,  checkout out his short bio on fedoraproject wiki.

(2) Install Counter Strike 1.6 using Steam Client. A piece of cake.

(3) Now the important part: go to your local steam directory
~/.steam
directory and create a symlink to provide all libs that are required by the game.
cd ~/.steam
ln -s bin32 sdk32
(4) Play!

I'm not hiding that I'm really excited about having Counter Strike running on my Fedora. It was exactly this game that made my switch to Linux really difficult.

I'd like also to point to one more thing. This wouldn't be possible without a major OS provider, whose attitude caused Valve to look for alternatives. It will be a bitter lesson for some people.

We, as an open source community, should never forget what happens if you ignore your users.

Happy fragging!

Tuesday, January 29, 2013

That's just unbelievable

I never thought it will happen. Thank you all, who made this. And thank you all, who caused this (including OS providers).


Counter Strike 1.6 running on Fedora 18





Instructions how to do that will follow soon.

Happy fragging!

Wednesday, January 9, 2013

Unmaintained libraries are a security hole - Call for Help

I was thinking about naming this post "A security hole in Eclipse" but that could be a bit too strong. But the truth is that unmaintained libraries are a big risk to the entire software stack, because there is nobody to look after them and release new versions.

I'm writing about this, because recently my eyes looked at Eclipse and bug 337449 - [transport] Consume httpclient 4 provider from ECF. It looks innocent, but is it indeed?

The HttpClient project website says:
The Commons HttpClient project is now end of life, and is no longer being developed. It has been replaced by the Apache HttpComponents project in its HttpClient and HttpCore modules, which offer better performance and more flexibility.
Now, if you drill down into the aforementioned bug, you will discover that there is a support for HttpClient 4 in ECF, although it looks unfinished. It is unfinished in that sense that it is not fully tested. So Eclipse Platform can't use it. So it remains untested... We really can't afford for waiting any longer.

So I have prepared an Eclipse Platform Build with httpclient4 for all major platforms. Please get it from my fedoraproject page and test it by installing anything from an update site. Especially if you are behind a proxy. And update the bug with results. It's needed to move that bug forward!

Here are direct links to Eclipse Platform with httpclient4:
Happy testing!

BTW. This would not be possible without platform CBI build system making the build process really easy.