Fedora Packager for Eclipse 0.2 released

The Fedora Packager for Eclipse development team is proud to announce our 0.2 release. What’s Fedora Packager for Eclipse? I’m glad you asked. In a nutshell it can be seen as an IDE for Fedora packaging. It helps you creating RPM packages for Fedora. Some might call it a GUI for fedpkg, although we don’t use it under the covers 😉 A picture says more than a thousand words. Here is a screenshot:

Fedora Packager for Eclipse Screenshot

Fedora Packager for Eclipse Screenshot

This release includes a lot of new cool features and even more bug-fixes and usability improvements. So what is it that’s new in Fedora Packager for Eclipse you ask? Here is a brief run-down of the coolest new features:

  • Local Fedora RPM project support
  • Keyboard shortcuts
  • SRPM based Koji scratch builds
  • Improved mock based builds.
  • SRPM import
  • Better Bodhi integration

For a more detailed list of new features and bug-fixes see our release notes. Our updated Fedora Packager for Eclipse user guide explains new and old features in detail. Fedora Packager for Eclipse 0.2 will be part of the upcoming Fedora 16 release. Can’t wait? Get it right now from rawhide (note that you will have to upgrade to Eclipse Indigo from rawhide for it to work):

$ sudo yum update --enablerepo=rawhide eclipse-fedorapackager

If you already have Eclipse Indigo you can alternatively install it from our p2 repository. Get it while it’s hot 🙂 We look forward to your feedback and hope you’ll like it! Many kudos to everyone involved making this our best release so far. Enjoy!


Generating Passwords

Here is a little snippet to generate some throw-away passwords in a script. You may have to install sharutils.

$ dd if=/dev/urandom count=1 2> /dev/null | uuencode -m - | sed -ne 2p | cut -c-8


Debugging Eclipse dropins

Chris Aniszczyk wrote a handy little blog post about debugging Eclipse dropins a while back which I’d like to share.

Why is this useful? That’s how packaged Eclipse plug-ins are installed in Fedora (for example). In a nutshell, a directory is dropped into a dropins directory system Eclipse knows about when an RPM is installed (e.g. by using yum). The name dropins kind of makes sense 🙂 When Eclipse is started the next time it checks timestamps on files and directories in those dropin-directories and if something has changed, will try to install them. No problem you say? Not quite. First note that all dropins installed bundles get marked as optional, so no error is reported when dropins reconciliation fails. Here is a scenario: Say the bundle you just installed using yum could not be resolved (for whatever reason), then Eclipse will just omit those unresolved bundles, since they’re optional anyway and just starts with bundles the user had installed previously. This is a problem, since the user thinks the plug-in is installed – the yum installation succeeded, after all – but in fact, the *real* installation happens when Eclipse starts the next time. This really is a very brief explanation of the problem and by no means complete. Take home message: one shouldn’t use dropins but use the p2 director to install Eclipse plug-ins instead.

In any case it’s useful to be able to discover dropins problems and this is what Chris described in his blog post. It’s fairly straight forward. Just create a .options file in your current working directory, put the following content into it and start Eclipse with: $ eclipse -debug -consolelog -clean (you might want to consider removing ~/.eclipse as well). The only required option is debug, but the other ones are useful as well.


After that you should see very verbose output which should give you hints as to why some plug-ins don’t show up in Eclipse. Happy debugging!