Eclipse, Android and Maven: Part 7 - Global properties and settings for Maven


For those who work on projects with multiple developers such as open source projects, you'd realise that the way I've currently set up Maven is not very good for multi-developer projects.

It's also not a good idea to have passwords or computer specific SDK locations in your pom.xml file because each developer will need to change the pom.xml in order to compile the code.

If you're fine with using script files to pass arguments to Maven then that's fine. Otherwise, you can set up the Maven global settings.xml file.


Machine specific Maven settings

It can be located in either:

  • %M2_HOME%/conf/settings.xml
  • %USERPROFILE%\.m2\settings.xml (aka ~/.m2/settings.xml)

Either way, the guts of it looks the same.

Open up your settings.xml file (you may need to create it for the user specific one).

I use this to store the location of my Android SDK home folder, Android SDK Maven repository and information such as keystore file and passwords.

The profile named "variables" sets up some properties for us which is automatically filled into your pom.xml file when needed.

The Android Maven repository is set up so you don't have to do it in every pom.xml file you work on.

And lastly, active profiles tells Maven to always use these the variables profile.

Once you're done, you'll need to reload the settings into Eclipse (if you don't want to restart).

  • Preferences
  • Maven
  • User settings
  • Click "Reindex" to update the settings

And that's it! We've finally reached the end of the Maven journey!


Time to go full pro at Maven now! I mean if an ostrich can ski that good, what's YOUR excuse?


Eclipse, Android and Maven: Part 6 - Sign your Android app APK for release


And now its time to sign your APK for release. This took a while to figure out due to all the conflicting information about ways of setting this up.

I've determined that the easiest way of doing this is to simply create a "toggle variable" that skips the signing process unless specified by the calling script / command line argument.


Setting it up

Open up your pom.xml file for editing, go to project > properties and add in:


This, by default, will skip the signing process.

Now scroll down to find the project > build > plugins and add in this:

<!-- Sign the APK with release signature -->
<!-- Required because it's initially signed with a debug cert -->



You may have noticed in the configuration that <skip> is controlled by ${sign.skip}, as defined above in the properties. You can override this by passing in command line arguments to mvn.

Similarly with the keystore, storepass, alias and keypass, they're all configured with properties or command line arguments. This is a good way of keeping your passwords out of the pom.xml file and source control.

Another point to make clear is that you NEED removeExistingSignatures. When the jar/apk is initially created, it's signed with a debug certificate. You have to REMOVE that before signing with your own, otherwise the verification goal will fail with this error:

[INFO] jarsigner: java.lang.SecurityException: invalid SHA1 signature file digest for res/drawable-xhdpi/abc_ic_go_search_api_holo_light.png

How to sign your APK

Normally, you'd just run this to create a debug APK:

mvn package

To create the release APK, type the following to begin the build process:

mvn package -Dsign.skip=false -Dsign.keystore=X:\your\cert.keystore
-Dsign.storepass=STOREPASSWORD -Dsign.alias=KEYALIAS

The "-Dvarname=value" specifies it's a variable being passed to your build script, which overrides any instances of ${varname} in your pom.xml file.

It's also a good idea to enable verbose output to test your configuration until it's working properly. Place this under the jarsigner plugin > configuration:


You'll probably also run into this warning message:

[INFO] Warning:
[INFO] No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2068-08-23) or after any future revocation date.

Don't worry, it's not too bad. The date is the expiry date of your certificate so it's fine if your certificate expires in an extraordinarily long period of time.

By now you should be able to produce a signed APK file, ready for release.


Copyright © Twig's Tech Tips
Theme by BloggerThemes & TopWPThemes Sponsored by iBlogtoBlog