I tried to make some progress on the Maven front with this pull request: https://bitbucket.org/kevglass/slick/pull-request/12/
Please check the pull request for practical implementation details. Ideally I'd like to keep both Maven and Ant working for some time to let people the time to get comfortable with Maven.
On the philosophical aspects I think switching to Maven would have some benefits, some that have not been mentioned yet:
- Simplify the build script maintenance, for example the current build.xml contains a lot of duplicated <javac>, <jar> tasks
- Have IDEs use the same build system and environment as the command line build. That would avoid issues such as the one that was committed recently where someone put an @Override annotation on a method, but @Override is not supported in 1.4. The build.xml file targets 1.4, but I suspect the IDE of the user wasn't configured for 1.4 so it didn't complain.
- Simplify / generalize the command-line build so that it can be built automatically using a continuous integration system (See "Jenkins", or "Travis-CI"). With that system we could have nightly-builds automatically published somewhere, as well as catching compilation errors or unit test failures when someone commits.
- Ease the migration from SVN to BitBucket: The BitBucket repository seems a bit "messy" due to the SVN import I presume. Having each project / module independent from the others (as enforced by Maven) makes it easy to clean up the BitBucket repository without the risk of breaking something. It also makes it more lightweight as in the end we won't have JARs stored in Mercurial. Additionally, other projects like the Android version could be made a sub-module next to the other tools, for consistency.
- Reduce the entry ticket for developers: If we simplify the Mercurial repo, and if we simplify the project structure and the degree of knowledge you need to have to build and run the framework, this makes it easier for people to contribute patches.
- Simplify dependency management and packaging, obviously, but I think that would also improve the user experience if we can somehow manage to package all the dependencies including the natives properly, which I believe can be done with Maven
Finally, and that's the best advantage I think, we could use Maven archetypes: http://maven.apache.org/guides/introduc ... types.html
This is like a project skeleton that you can create with a single command line. We could have a "slick-game" type skeleton that users would use to generate their project structure. That would come with all the dependencies properly configured, the build configured to package the game in various format (ZIP, JAR, WebStart, you name it), it could also contain a basic Game class that just displays an "Hello world !" as a starting point.
That would definitely make things easier for users if they could create a functional Slick2d project just typing a single command. It would also help with their IDE setup, as they'll only have to import the Maven project to get it going.
Let me know if there's interest or not in such a thing, I'd be very keen to have Maven support but I don't want to waste my time if the project leaders think it's unnecessary.