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:
We agreed to switch to Git over the next few weeks. General outline
- Get rid of external references in SVN
- Convert SVN repository to Git repository on Google Code
- Fix mirror on Github
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.
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