Libgdx Maven Support

Today i kinda finalized our Maven support. You can read all about it on this fine wiki page.

The Maven support includes:

An archetype that will setup the core, desktop, Android and HTML5 projects

Ways to package your application for the desktop, Android and HTML5

Ways to run your application from the command line for the desktop and Android

IDE integration with Eclipse and Intellij Idea. The latter is a bit untested, doing so as you read this.

This was quite a bit of an effort. We lifted a lot of work from Michael Bayne’s PlayN archetype, Team Gemserk (arielsan and ruben) helped with writting a libgdx mavenizer that takes a distribution zip and creates artifacts/poms from it. They also wrote the fine maven natives plugin and hacked m2e-android to support relative asset paths.

This is all experimental at the moment. We are waiting on the m2e-android project to merge in a pull request and publish their plugin to the Eclipse market. For now you’ll have to compile and install this plugin from Gemserk’s fork. The archetype also needs to be installed manually from source.

I hope we can publish the artifacts and the archetype to Sonatype as soon as Ruben is back from his vaccation. Then you can easily create your projects without having to manually compile anything.

The iOS backend is currently not support. I first want to fix up the gdx-setup-ui before diving into this.

And because i had so much pain while creating this with the help of all the other folks, here’s a rant for you. I’m used to Maven and use it quite heavily at work. It works brilliantly there, but there’s a difference between that environment and what we do with libgdx. At work, we run in desktop environments only. This works with any IDE easily. For libgdx, we have to deal with a ton of IDE specific issues due to the different plugins for Android/GWT, e.g. Eclipse not being able to cope with relative paths (what a bunch of bullshit). Most of the work on Maven was figuring out how to work around all those Maven/IDE specific limitations. I gave up on Netbeans, so if someone can figure out how to get the archetype working there, send me a pull request. Intellij Idea and Eclipse should work. The state of Maven, IDE plugins and Android/GWT is a horrible one, and i would not recommend anyone working on that who wants to keep his sanity. I’m not looking forward to make all this work with the upcoming Groovy based Android build system :/

10 thoughts on “Libgdx Maven Support”

Trying it out in Intellij, it assumes you will list all the children modules in the “” tag to automatically pick up the modules. You as a developer can always configure the modules you care about of course in Intellij or update the pom.xml appropriately.

The only thing I found “fishy” was after building all the modules I found a “war” folder was created at the root of my test project. Not sure if this was intended or it is a “fix” for the IDE GWT plugin madness.

I perfectly realize that getting libGDX to be subjected to maven and mavenized was and is not an easy task; we’ve done few things locally already, but probably would switch to your solution in the future. We have been waiting for proper GDX + Maven integration for quite a while, as Maven is what is used to assemble and package many complex (I mean, with multiple external dependencies) projects out there.

Will give it a try next week, I guess, as this week is kinda short and has almost ran out.

I do want to check things out when it gets a bit more finalized. Thanks for the heads up though I can’t say I’m bummed about Android adopting Gradle since that is the tech I’ve been eyeing to back my configuration / setup tools for my efforts. I dug up this link with a little more info on what is going on with the Android side:http://tools.android.com/tech-docs/new-build-system

I did try to install PlayN before LIBGDX which used Marven and it failed and there was no help I could find for the errors and I gave up. Perhaps I am a more creative than technical game developer, but setting up some enviornments is just too problematic. LIBGDX is easy, and I hope it stays that way.

Maven has a few benefits like easier packaging/building for a specific platform, easier inclusion of 3rd party libraries and their dependencies, IDE independance (not entirely true). That being said, it can also be a huge pain in the ass at times.