Igor’s blog

In the past few weeks I spent some time preparing patches that backport PyDev (the Eclipse Python plugin) from Java 1.5 to 1.4 so that it can be shipped in Fedora, since for some time now PyDev has been developed on Java 1.5. Last week I updated my patches to PyDev 1.1.0, which is the latest version that will support Eclipse 3.1.2, and so the latest version that can go into FC5. Last week version 1.2.0 was also released, which is the first version that will be targeted for Eclipse 3.2, which is what will get into FC6.

I spent some time last week trying to make PyDev has sane defaults out of the box for settings like the path of the Python and Jython interpreters, I got something sort of working, but it wasn’t quite there yet. I’m planning to push PyDev into Fedora Extras in FC6, since it will now have an optional dependency on Jython. But I’m wondering whether I should release 1.1.0 as a Core 5 update, because it really is a *huge* update in stability and functionality over the version we currently we have in. I’ll probably try to make a test RPM that has the Jython bits ripped out tomorrow and push it into updates-testing, and see what kind of reaction I get.

Over the weekend or maybe next week I’ll probably prepare the PyDev 1.2.0 patch and a corresponding SRPM, that I’ll submit to extras pending on my other submissions (Jython and friends).

As I mentioned 2 weeks ago, I decided to backport PyDev 1.0.6 to Java 1.4 so that we could include it in Fedora. I’m glad to say that I’m done, and the patches are available here . Fabio, the author of PyDev, has released versions 1.0.7 and 1.0.8 in quick succession last week, which are bug fix releases, so I’ll be updating my patches for that shortly.

Right now I’m working on getting Jython into Fedora Extras because PyDev has Jython support. I could disable that support, and push the PyDev update into Core. But I decided it would be better to get Jython in extras, it’s a pretty important package I think. What I’ll probably end up doing once that’s done is splitting the PyDev SRPM in to several binary RPMS and make the eclipse-pydev-jython one depend on Jython itself.

If anybody is willing to be the shepherd of any of the 5 packages that include Jython and it’s dependencies in Extras let me know, as I probably won’t have time to maintain them.

Red Hat’s Toronto office recently got 6 new interns. It’s going to be a fun summer with 13 interns sitting together in one cube area .

Other than yelling very loudly for the whole day (I swear we were quieter last year!!) the interns are working on some improvements to yum. They’ve all used Eclipse before so they naturally wanted to use it. Very quickly they learned that we ship PyDev and so they tried that. Unfortunately we can only ship versions < 0.9.6, and currently we have 0.9.3. Even more unfortunately 0.9.3 sucks. Mostly because there were tons of additions and fixes since then, possibly also because of the way we’re running it, or because of GCJ. In any case, I decided that we *really* need to have a newer version, because this one is pretty close to useless as it is.

In the next few days I’m going to look to backporting PyDev 1.0.6 (latest released) to Java 1.4 and then pushing that as an update to FC5. We don’t have to do this often, but if it only takes 2 days, I can repeat the procedure before the end of the summer (when I’ll be going back to school). And then we could either repeat it again a few months after or just wait until we have real 1.5 language feature support (I don’t think PyDev uses any new library features, except Genericsized collections).

Yesterday I uploaded a new update site, made by Jeff Pound, for the Eclipse plugins we ship in Fedora. We now finally have both the ChangeLog and Bugzilla plugins in the same update site, which should be much more convenient. The main problem that we’re seeing with this is that we currently do not support the 3.2 builds, only 3.1.x, this is because the plugin depends on a patched up org.eclipse.compare plugin. The patched version exposes API that is internal in the official Eclipse.org version, and this allows us to apply patches from bug reports to projects in the workspace. Unfortunately these patches by Jeff were largely ignored by the core Eclipse folk, and are not committed to the 3.2 branch. On top of that the code that the patch applies to is still changing, since it’s internal API that the patch exposes and is not covered by the API freeze. So for now we are only supporting Eclipse 3.1 in the Bugzilla plugin. In the near future we may branch it so that we have a cut down version without the patch functionality for 3.2 (which is not that huge of a deal anyway). But we still need the internal API to stop changing for this. I guess we’ll wait and see.

In the past 2 days I’ve been trying to update the Bugzilla plugin before Fedora Core 5 test 3. I’ve been trying to make it play nice with the Red Hat bugzilla through the XMLRPC interface instead of html-scraping. The functionality was already there but I discovered that Eclipse couldn’t find the jar file that contained the Java xmlrpc library , which was located in /usr/share/java. I decided to stick the jar in the plugin and be done with it. Boy was I wrong. It took me a whole day of head-banging on Monday to *not* get it working. Seems like a pretty simple issue, getting a plugin to recognize a jar *inside the plugin*. But apparently getting a jar file onto the runtime classpath is a fundamentally difficult problem. Yesterday morning after talking to some eclipse people on IRC I got a link to this life saving post, that lists 6 steps to ultimate happiness. Half an hour of checking, testing, rebuilding and more testing and I was done.
Granted I should have gone and asked a bit earlier (how about a day?) but the fact that I was tweaking the same settings for a whole day and managed to not stumble on the correct set is also telling.