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 :)

8 thoughts on “Git & Maven

  1. +1 for maven and git.

    I’m making an online game with libgdx and have many dependencies upon server modules and it goes pretty well with maven. One problem remained is sharing the assets folder between desktop and android module.

  2. This move to git is awesome; just in the nick of time! I will be merging my Bitbucket fork (https://bitbucket.org/robertmassaioli/libgdx) over to whatever repository you make and merging all of my changesets back into it too. Are you going to use git-svn to do the changeover?

    I also use Maven at work and I too agree that doing it the way that you currently do works very nicely. Also, maven is slow when you get many dependancies and things happening. Ant is still quite fast at getting the job done so I would stick with it until you absolutely have no other option.

  3. I just listened to that whole conversation. The final conclusion is a good one. Just a few points:

    – Do not keep a git and svn repo alive at the same time. Choose one or the other and do a clean migration. I believe that is the final plan but I just want to re-affirm that.
    – Some of the people were joking about maven and I agree with your reasoning. It is not a perfect fit for libgdx. However you are paying for that in repository size. The repository would be nowhere near as huge if you were not committing binary / compiled files into the repository. Maven would remove that problem (and arguably replace it with another).
    – I agree with your logic to keep everything in the one system. If you used Github or Bitbucket then you should use their issue tracker and wiki too so that all of the information was in one logical place. (I actually think the Bitbucket bugtracker is nicer than the google code and github ones but to each their own). At any rate if you want to stick with the google code wiki and bugtracker then keep the code there too.

    Other than that there was a lot of fun talk which was interesting to listen to. I am guessing that I was one of those people that prompted this git change? If so then I fully support it! Good move and I am sorry that it cost you your svn extensions. We will dedicate a commit message in their honour!

    The second that the git code comes out I will start merging my minor changes back in. I have not done anything significant yet. Keep up the awesome work.

  4. Glad you are making the move to GIT…I made the switch a couple of month ago and now I think SVN is the biggest pile of shit, after IE6 of course.

    Good to see you made the effort and dressed up for your chat :-p

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>