Eclipse Fedorapackager 0.5.0 release

After a bit more than 2 years it was high time to do new release to adapt to current Fedora and Eclipse releases. Most of the changes in this release were towards cleaning and simplifying the codebase hoping for faster releases but there are some important feature changes like:

• Fedorapackager requires Java 8 now.
• Allow users to clone multiple projects at once.
• Fix changelog parsing for Bodhi
• Make use of /etc/rpkg/fedpkg.conf
• Modified Fedora Packager Koji properties page
• Reduce logging noise.
• Enable rpmlint and rpm natures by default.
• Tagging is no longer used with Git.
• Shorter menu labels.
• Fixed JsonNull error when pushing bodhi update
• Eval NVRs when Bodhi updating
• Eval the name to not fail on sclized packages.
• Bodhi authenticate when pushing review fix.
• Bodhi dialog cleanup.
• Make perspective switch remember previous choice.
• Let the console name has the package (srpm) name in it.
• Remove expectation of the existance of an ssh key.

Updated packages are available in Rawhide and Fedora 21 updates-testing.

RPM + OSGi automation: Step 1 completed

Recent RPM versions include the concept of dependency generators. This opens the door for a number of automations and simplifications for people using RPM as their distribution format. 

In Fedora we stepped in and worked on making Java land fell less of an alien in Linux distributions. 

Not every OSGi feature is considered because some of them don't match with the goals of distributing a single project. Everything is based on the Bundle-SymbolicName and Require-Bundle headers (for now). 

• Bundle-SymbolicName header is used for generating a virtual provide for the rpm the bundle is part of in the format Provides: osgi(bundle-symbolicName) = bundle-version . This is done for every OSGi bundle in the RPM so the number of these provides will be the same as the number of bundles in it. This provides generation was enabled early in the Fedora 17 development phase and will be available for use in the soon to be released Fedora 17. How will this improve the packager's life one may ask?  - Do you know which package e.g. javax.servlet bundle is in? You don't have to anymore. Put Requires: osgi(javax.servlet) in your spec file is all you need. Or you can use yum to query for it `repoquery --whatprovides "osgi(javax.servlet)"`

• Require-Bundle headers are used for auto generating requires so people don't end up with dependencies not being installed. The format used is pretty much the same Requires: osgi(bundle-symbolicName). Few things needs mentioning here - optional requires are discarded because RPM(in Fedora) doesn't have the concept of soft-requires and versions are not added to the requires for a reason that will be explained later. The requires generator have just been enabled in Rawhide(future Fedora 18) and up to now it's showing no major problems with a pretty huge test case - the Eclipse SDK.

 Import/Export-Package is a huge part of the OSGi specification and even the recommended way for specifying dependencies. Here I'll explain why it doesn't make sense for RPM packages without questioning it's general usability, it just doesn't fit our workflow.

• having provides/requires for every package import/export is way too verbose and will polute the rpm metadata that much to make it hurt every user with unneeded time to download metadata
• we don't want multiple providers for the same package - we want  a single, stable and well tested provider. 

This is big enough difference to even make me think of Step 2 where Import-Package headers are used at build time to map them to Require-Bundle. This will not be an easy task but it is possible because at build time we know which bundle exports the needed package. 

Now to not having versions in requires. First of all there is no easy mapping between OSGi version ranges and RPM. OSGi recommends using version ranges while in RPM it's considered a really bad practice to use anything else but setting the lowest version supported. Second, we usually have only one package that provides given osgi bundle. Third , more than one OSGi bundles are usually grouped in a single RPM. All of the above combined makes the requires generated satisfying 90 % or even more of the cases and for the rest one can still add the requires manually (like we do now).

This isn't by any mean a complete solution it covers only the most common case but still it will prevent a number of problems like Eclipse failing to provision because of missing requires for some plugin and etc. Once the current automation makes its way through the whole distribution work on the next integration step can continue because there would be less time spend on simple but timeconsuming things.

Maven and RPM - one problem less

Are you packaging Java software?

Does your package use Maven as a build system?

Have you wondered what package provides certain Maven artifact?

If you answered yes to at least one of the questions there is a good news for you:

Fedora's build system is going to automatically generate RPM Provides in a sensible way for Maven developers.

Now the details. Big thanks goes to the RPM developers for the new Dependency Generator which has made our work so much easier.

With just these 2 simple files maven.attr and maven.provwe get it to the state where every package that installs pom files according to Fedora Java Packaging Guidelineswill get provides added for every pom installed in the form mvn(groupId:artifactId)where groupId and artifactId are the same things you know from your Maven experience. Look at this recent maven2 rebuildfor example what will be generated for a package with many pom files installed.

It might look a small thing but I'm really looking for the day when I'll be able to write BuildRequires: mvn(org.apache.maven:maven-script-ant) and not having to guess whether this is part of maven package or maven-plugin-tools-ant or maven-shared-ant. And these days are near for rawhide when we get the critical mass of rebuilds done so the provides are in place.

This opens an enourmous opportunity for improving a number of things like:

* when you get a build failure in your maven build - you should be able to just write yum install mvn(groupId:artifactId) and have the package ready. Who knows we might even find someone to create a PackageKit extension in the way bash command-not-found is acting?

* tools like RPMStubby will be able to generate proper BuildRequires section without guessing how did the distribution renamed the package

* use your imagination

There is a possibility to add similar support for the requires generation but lets first do all the fixes/simplification this one gives us.

Happy packaging to all Java and Maven packagers!!!