There are two recent changes to our Java guidelines in Fedora and use of Maven when packaging that I'd like to mention today

Maven dependency mapping macros

Thing I haven't blogged about yet but it's pretty important: We have new macros for maven depmaps in Fedora. In the past when you wanted to map certain groupId:artifactId to a file in _javadir, you had to include snippet like this in your spec:

%add_to_maven_depmap com.google.guava guava 05 JPP guava
%add_to_maven_depmap com.google.collections google-collections 05 JPP guava

This tells our maven that com:google:guava:guava and com.google.collections:google-collections can be found in one of the repositories as JPP/guava.jar. It meant you had to know the groupId:artifactId and other information, plus it was extremely easy to make a mistake here causing all sorts of trouble. Current code doing the same thing:

%add_maven_depmap JPP-guava.pom guava.jar -a "com.google.collections:google-collections"

We parse the pom file and get groupId:artifactId from it, plus we do additional sanity checks such as:

• naming of pom and jar file have to be consistent
• jar file has to exist if packaging type is not pom

If you need additional mappings you can easily add them. There are few other options for this new macro useful in certain situations.

Maven test deps skipping

Long story short: When you use -Dmaven.test.skip=true in Fedora packages you no longer need to patch those test dependencies out of pom.xml.

We've had Apache Maven in Fedora for quite some time and packaging using Maven has been getting easier over time due to small tweaks to our packaging macros and guidelines changes. However there has been one problem that's been bugging all Java packagers and was especially confusing for those starting to package software built with Maven. The problem is that Maven creates a tree of dependencies before it starts building the project, but it includes test dependencies even when tests are being skipped.

Skipping tests is sometimes necessary due to problems with koji, or dependencies and up until now we had to either patch those tests dependencies from pom.xml or use custom dependency mappings (ugly concept in itself).

Last week I decided it's about time someone did something about this, so I dug in the Maven code and created a solution (more of a hack really) that is already included in Fedora. If you want the gory details, you can read the patch itself (I advise against it). I'll try to make the patch work properly so that it can be included in mainstream code.

I can just hope that packagers will find these changes helpful, but general feedback has been positive.

I have been doing proxy-maintainer now for a few people and I found strange problem with fedpkg clog in relation to git format-patch and git am.

If you have a changelog message like this:

* Mon Feb 28 2011 Stanislav Ochotnicky  - 2.1.1-1
- Update to 2.1.1
- Update patch
- Disable guice-eclipse for now

fedpkg commit -c would create git commit message like this:

commit 22b5306036b6ef1022498b63e40324370ff7159b (HEAD, f15)
Author:     Stanislav Ochotnicky 
AuthorDate: Fri Aug 26 11:45:54 2011 +0200

    Update to 2.1.1
    Update patch
    Disable guice-eclipse for now

This works fine and mighty as long as you don't try to produce patch from this commit. Let's see what happens with git format-patch HEAD~1.

$ head 0001-Update-to-2.1.1.patch                                                                                           f15 [22b5306]
From 22b5306036b6ef1022498b63e40324370ff7159b Mon Sep 17 00:00:00 2001
From: Stanislav Ochotnicky 
Date: Fri, 26 Aug 2011 11:45:54 +0200
Subject: [PATCH] Update to 2.1.1 Update patch Disable guice-eclipse for now

After adding this patch to repository using git am the line breaks would disappear. This is because git expects empty line after subject and description of the commit afterwards.

I decided to try and fix fedpkg clog a bit. Given the previous changelog, now it creates git message like this:

commit 768964ce2145ef2b472fc5ef8781fb036d586b0e (HEAD, f15)
Author:     Stanislav Ochotnicky 
AuthorDate: Fri Aug 26 11:57:20 2011 +0200

    Update to 2.1.1

    - Update patch
    - Disable guice-eclipse for now

This means that git format-patch can do the right thing. I filed bug report for fedora-package so hopefully we can have this fixed sometime.

*Edit:* Yes, there is fedpkg lint but it somewhat limited so read on. Instead of addition of "rpmlint" command Pingou will improve current lint

Recently I was trying to help OpenSuSE guys with some updates to their Java stack and I was sent link to their build system. I noticed a file called jpackage-utils-rpmlintrc and this got me thinking...

What if we added rpmlint command to fedpkg with per-package rpmlint ignore settings? Turns out Pingou took my idea and implemented it in under an hour :-)

An example run:

$ fedpkg rpmlint
plexus-interpolation.spec: W: invalid-url Source0: plexus-interpolation-1.14.tar.xz
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

plexus-interpolation.spec: W: invalid-url Source0: plexus-interpolation-1.14.tar.xz
plexus-interpolation.src: W: spelling-error %description -l en_US interpolator -> interpolate, interpolation, interrogator
plexus-interpolation.src: W: invalid-url Source0: plexus-interpolation-1.14.tar.xz
1 packages and 1 specfiles checked; 0 errors, 3 warnings.
2 packages run
rpmlint has not been run on rpm files but should

OK, so we can run rpmlint on spec, srpm and binary rpms with single command. But I don't like to see the same warnings all the time, because that means I will probably miss real problems when they appear. For this fedpkg rpmlint uses .rpmlint file as additional rpmlint config. So after creating:

$ cat > .rpmlint << EOF
# we have scm checkout with comment in spec
addFilter('invalid-url')
# false positive
addFilter('spelling-error.*interpolator')
EOF
$ fedpkg rpmlint
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

1 packages and 1 specfiles checked; 0 errors, 0 warnings.
2 packages run
rpmlint has not been run on rpm files but should

Cool right? Pierre sent patch with this feature to fedpkg developers, so hopefully we'll see this addition soon. I then plan to add custom .rpmlint configurations to all my packages so that they will be warning-free.