Slick Forums

Wow, thanks. I'll take a look at your changes. And the reason that the default is the outdated Maven 2 was a copy paste error from a really old maven pom I wrote. I was being lazy, oops.

Second, the change to Maven 3 may break some of the plugins. I'll look into that, if you haven't already.

The Maven reporting plugin is useful of course, but I was trying to emulate the old build scripts as exactly as possible, and then look at optimizations + additions. Convincing the devs that prefer Ant that Maven is so much better may be difficult, so I wanted the build script behaviors to be as exactly the same as possible.

EDIT: Why do I see binaries in the repo? Please get them out ><. It's so so so anti-Maven to include the dist/libs in the source. It also violates just about every source repo paradigm. I was trying to get Slick away from this.

_________________

Regarding the binaries, I know that keeping them in the tree is bad practice. I wanted to keep a record for the moment so I would make sure that I would deal with them, especially the jnlp. Note that they are in your repo as well.

And so they are. Wtf.

DAMN YOU MERCURIAL.

My local repo doesn't have them in the source tree. This is my mercurial n00bness showing, as I have really never used it before Slick. Somehow my local and remote repos are out of sync.

_________________

try

This is a force sync so it will blow away any current changes.

I'll just wait on your fork. It'll make merging easier, since the directory changes make everything complicated.

_________________

I pulled the current tip of your branch into my repo.

_________________

Cool. Thanks! There is still a lot of work to be done and I plan to work on it this week.

Dave

Hi all,

I have made progress on the Maven build system. I still need to work out the webstart stuff though. One question, since ibxm is the only core dependency that is not in the Maven Central repo can we drop it from Slick? I understand that is only used in the ModSound class which is not used.

Dave

Why don't I take a look at that class and see if we can replace it's functionality with a class based of a different dependency?

_________________

Thanks!

Hi,

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.

Cheers !

Nico

Ah, I knew I forgot a bullet point

It would also make versioning better: The current system of having Ant increment the version number is working when you're working alone on the project, but doesn't work anymore as soon as 2 developers are contributing ! It's frustrating not knowing which is the version that is downloadable from the Slick2d website, where to find the corresponding Javadoc and sources in the same version, etc.
Having proper version numbers (1.2.3) with Maven would help, and publish those artifacts using the Maven release system would make it easier for people to know which version they're using. It might also help with bug reports because you can't really know which version the user is running when a bug is reported...

Cheers,

Nico

+1, just only for slick version !

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

Since there doesn't seem to be much interest in switching to Maven for building Slick (no answer to my previous post or my pull request) I've taken a different approach: Package a Maven distribution separately and keep the sources in sync with the development branch (from BitBucket).

Check it out: https://github.com/nguillaumin/slick2d-maven

I also implemented a Maven archetype to get a basic game skeleton going in two commands. This also deals with properly packaging the game with all the dependencies. Eclipse integration is made really easy (zero config) with the Maven Native plugin. The URL above has all the details.

Comment and feedback welcome !

I just open an issue, hope helps!

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute