Git Move Step #1 Complete

I just finished removing all the externals. Wasn’t so bad after all. We only had external refs to tablelayout, bullet and soundtouch. If you run into problems when updating your working copy, just do a clean checkout.

Next up: playing around with a temporary git repo so i can figure out how to transfer all our history, branches and tags. I need to do this before i kill the SVN repo on Google Code. May the FSM be with us.

Changes in ADT 20 break your libgdx Android builds

I love the activity on the ADT project, lots of nice new changes are introduced. They are also reworking the build system. However, in that process, some irritations turned up that made our lives a little bit less enjoyable from time to time. Watch the corresponding talk from this years I/O to see where the journey leads.

Since ADT 20 there’s a problem for the common libgdx setup (and other setups where you share code between, say your servlet and your Android app). Scenario: you have an Android project and a standard Java project in Eclipse. The Android project depends on the Java project. If you change things in the Java project and then run the Android project, ADT used to recompile the Android project to include the changes from the dependency. This is no longer the case, you’ll have to clean and rebuild your Android application for it to pick up changes in your Java project.

In any case, if you care enough, please star this issue: http://code.google.com/p/android/issues/detail?id=36174&thanks=36174&ts=1344514616.

Do not add “me too!” comments, just star the issue and call it a day.

Git & Maven

We had an ad-hoc Hangout (Nate, Ruben, Arielsan and me). We talked about moving to Git and pushing artifacts to Sonatype. Here’s the video:

Git

We agreed to switch to Git over the next few weeks. General outline

  1. Get rid of external references in SVN
  2. Convert SVN repository to Git repository on Google Code
  3. Fix mirror on Github

External References

We decided to get rid of the external SVN references. Those are currently used to pull in specific directories from projects like TableLayout, libmpg123, tremor, bullet physics, kissfft soundtouch and so on. The reason is that we want to follow changes in those projects as closely as possible. On every SVN update, we pull in the latest commits from these projects. If something doesn’t work, we’ll get to know by our build server sending us nasty mails.

In reality, those external dependencies do not change that often. We will thus get rid of the external dependencies, manually copy specific versions of each project into our SVN trunk and update our Github mirror accordingly. That is the first step.

Converting the SVN repo to Git

The second step is to convert our SVN repository to a Git repository. We’ll do this on Google Code. We talked a lot about this, here are the reasons why we stay with Google Code. We like our issue tracker and wiki. We could 1) transfer that to Github or 2) we keep the tracker & wiki on Google Code and have the code on Github. Option 1 isn’t nice, we lose all kinds of wiki functionality and it would be painful to transfer the issues to Github. Also, Google indexes our source code on Google Code, i often just type the class name plus libgdx into Google to quickly get to a source file on my phone.

Fixing the Github mirror

However, by converting our Google Code repository to Git, it will be very easy to react to pull requests, thus making contributing features and bug fixes a lot easier. We can easily process pull requests on Github as will by simply hooking up our Google Code repo with a Github mirror.

Maven

I like Maven for enterprisey projects that run on desktop operating systems and don’t have dependencies on native code or other fugliness. Apart from the benefit that managing dependencies is a lot easier (*cough*), it also allows each team member to work in whatever IDE he or she likes. At work, some people use Eclipse, others use Intellij, some might even use Netbeans. By using Maven, it’s really simple to support that kind of development environment.

It becomes a different story once you mix in native code (or even native code builds!) and other platforms, like GWT or Android. Maven support for these things is painful or even non-existant. That’s one of the reasons why we didn’t go with Maven from day one. Another reason is that dependency managment for multiplatform projects that also run on Android and especially GWT is something that’s not necesserily better or easier with Maven. Most dependencies you pull in via Maven won’t work in GWT, Android can be a problem as well. Additionally, you usually don’t have to many dependencies for games. The most common dependencies are libraries for social network integration, in-app purchases or ad networks. Instead of adding the burden of managing a fully mavenized multi-platform project, people tend to just throw their few additional jars into the libs/ folder and call it a day. Or (worse?) directly link to source, as is the case with the Facebook SDK.

TL;DR: there are a lot of reasons why we didn’t add Maven support to libgdx.

Now, Gemserk (Arielsan, Ruben) are Maven addicts and already wrote a nice project that takes a libgdx release/nightly build, extracts things and generates artifacts from them. We want to integrate that with our build server. It will build snapshots every night and deploy them to Sonatype, for which we already have an account. We’ll also deploy release builds. We’ll deploy artifacts for gdx core and all the backends. Extensions might be added in the future. However, we will not provide an archetype for the time being.

And that’s that 🙂