JME3, Maven, and a Maven Repository

I know there have been several posts on this topic, but the newest is a couple month old and I think it is worth revisiting. I think it would be great if JMonkey worked with maven out of the box.

Now it would be awesome and a worthy goal to one day have maven in the Central maven repository. There are some steep hurdles to do this though, the main one being JMonkey’s 3rd party dependencies that are also not in Central. Also, some of these dependencies apparently have JMonkey specific customizations? I believe I heard that, correct me if I am wrong. Bottom line though is it seems a daunting task to get JMonkey into Central with the current state of things.

There is another option in the meantime though. Set up a JMonkey specific maven repository. This is what Nifty Gui has done: The documentation about it is in their Getting Started page. I am currently hitting their repository for my projects.

With JMonkey’s own repository you can upload all the 3rd party jar dependencies easily, and version them under some custom version. In my custom maven repository, I have all of JMonkey’s dependencies marked as version ‘jme3.alpha2’ (so that they do not conflict if I have any projects which use other ‘real’ versions) under the group ‘com.jmonkeyengine.lib’.

At first the tagged versions of JMonkey (and its dependencies) would be available but eventually the nightly builds could also be made available (so ppl could always have maven automatically updating them to the latest JMonkey snapshot.)

I am willing to help work towards this goal in any way possible including getting a JMonkey Maven Repository configured, and working on the JMonkey pom. I know fellow maven users would LOVE to see this happen. The major step would be figuring out where to host the maven repository. NiftyGui is hosting theirs on SourceForge. I use an open source program called Nexus on my own webserver for my repo.

Let me know your thoughts on this matter.


PS: Off topic but when is Alpha3 coming? Can’t wait lol.

No thanks :slight_smile:

As you say, the whole shebang would have to be maven, each time we add a new library we’d have to wrap it to maven or ask if theres a maven repo etc etc… We’re fine with ant :slight_smile:

Edit: Also, handling of library fixes etc. is done via the jMP update center. As soon as jMP goes beta there will always be a fixes branch in svn for jME and jMP so you can switch between stable+fixes or nightly version easily.

You can do a project in both ant and maven, they are not mutually exclusive. And as for ‘wrapping it with maven’ it is not that hard. With Nexus for example its a simple upload.

Maven allows you to get either the latest snapshot OR a stable version with on change to a pom file. One wouldn’t have to mess with SVN, trying to get something to build, and all that hassle. Ant can also be configured to use a maven repository, so it helps out ant guys also.

Many developers use maven and having them have to basically host their own repository and upload everything custumly to their repo, just to USE JMonkey correctly seems a bit insane. Maven IS now used my a good number of developers for its ease of use and the fact it will automatically grab all dependencies (snapshots or stable releases) I am not trying to get into an ant vs maven argument or anything, and I suggest both be supported (though as I stated ant can easily fetch from a maven repo).

Why do you not want this? I am offering to work with you on this. It is something that keeps getting asked on the forums (ppl wanting to use maven) so it is a wanted feature. I figured I would volunteer to help make it happen.


EDIT: As for your comment about the JMP update stuff… that really means nothing to me as I don’t use that, I use maven (as I have MANY other dependencies in maven), and I use eclipse. I am not against using it, (instead of eclipse) but I fail to see how the library updates would be compatible with how I am building my project in maven (which as I said JMonkey is 1 of like 20 different dependencies ATM)

Yes, I can imagine that people with a maven workflow would find it very convenient but it is not for us. Wrapping for maven is also possible but I think its better when people do that on their own so theres no strangeness. Our eclipse project for example is also not updated properly and we had lots of people who said they would take care of it.

Btw, you can use your maven projects with jMP, its not fully tested but it should work like a normal jMP project.

Well that is unfortunate. I still don’t see how ‘its not for us’ when its an additional feature not taking anything away. Users obviously want/need it. It is easy to set up (took me 20 min initially for my private repo), benefits both ant and maven users, and all it takes in a bit of maintenance to upload a new copy of a 3rd party jar when you make some customizations to it. As I said It WOULD be nice to have w/e is doing your nightly builds to upload a new snapshot as well but even that is not required. The bare min just seems so easy to do >_<.

As I said I currently have it working just fine (as long as I use a release like alpha2, or alpha 3 w/e it finally comes out and not a nightly build). It is just that mine is on a private repo and I know others are in the same situation. I wanted to help others in the community and have your blessing on such a task. I still don’t understand your reasoning at all but if that is the final word I don’t have any recourse. The best I could do completely on my own would be to create a repository myself (like my private repo only public) and manually check with every release if any of the 3rd party jars changed. If I did such, could you at least make a reference to it on a wiki page or such as a ‘non-supported’ but workable maven repo?


PS: As for jMP I would rather not use something ‘not fully tested’ that I see no documentation for on the site and only just now heard of it. For the moment I see no reason to abandon eclipse, and it is the editor I use with ALL my Java projects and is the editor the rest of my team uses. (One does also uses Netbeans which I know is what the jMP is based on so I will let him know). I like having one editor to do everything (same warnings, same plugins, same color scheme, same formatter, etc)

See? You have it working just fine and any big project would use its own modified sources anyway.

About the jMP maven support: Would have been cool if you could have checked on the support for maven in jMP and give feedback, this way you could support the project and your favorite java build system :stuck_out_tongue:

I am not sure I know what you mean with the ‘modified sources.’ If you are talking about using modified 3rd party libraries, I would have to disagree. I mean most libraries are extensible enough that you don’t have to modify them. Otherwise it is a continuous hassle to continuously merge in the new changes with your customizations. It is quite a pain. I have worked on a good number of projects both large and small, solo, as a team as a hobby, and professionally at a company, and have only had to do this once or twice. Ironically one time it was BECAUSE they were not using maven for their nightly builds. It was to put in modifications for a future feature that was going to be available in their next release. Once they came out with a final version (and uploaded it to the maven central repo) we immediately switched. Now I do understand JMonkey is in a special position as many of the 3rd party libraries rely on native bindings and such, and other reasons. I am just saying that most projects I or my team have worked on, this has not been an issue which is why maven works so great.

No it is not hard to put the JMonkey up on a repo yourself. It is just a lot of redundant work that EVERY ONE who wants to use maven realistically has to do. I mean honestly, if every one took your stance, maven would suck. The thing I and many others LOVE about maven is the ability through a line or two, to bring in almost ANY dependency instantly. As I said I have like 25 or so dependencies (not including JMonkey’s), some big name libraries (google guice, apache-commons), some small nitch libraries. If I had to go find the jars (and update these jars every time a new version came out which maven AUTOMATICALLY checks) and put them all in my own repo I would go insane. That is a horrible way to do things. Luckily I don’t have to, I only have to with JMonkey (and its 15 or so libraries). The project I worked on at my last job was even more crazy, had 140 something dependencies(many small ones, but ones that were on maven none the less). Managing these becomes a breeze with a remote repository (the same is true for ant using a maven repo).

Sorry, just a bit frustrated. I will quit rambling. I understand there are reasons for everything. I just wanted to improve something many are looking for that I found odd JMonkey did not support. If it is not wanted, so be it. If you don’t mind I am still going to look into hosting a public repository to help out others using maven when they ask. Not sure if I can do that feasibly, I will let you know. :wink:

About jMP maven support, eh I was a bit unfair and just flustered. If I find some time I will look into it to see if it is usable. My main concern is maven still has to have the 3rd party dependencies specified, and for jMP to compile projects against the maven specified ones not its own, otherwise the build will fail on my autobuild server which HAS no jMP installed and works fully through maven. (Hudson if you are wondering)

See you around,


Afaik the maven support should take care of that by adding the required maven svn download etc. commands to the project / pom stuff or by wrapping the libraries similar to the way you do it when they come from the internal jMP library. Also sorry from me, but you know the next guy might find an osgi package convenient and not to mention all kinds of linux distribution formats, some would like us to use mercurial or git instead of svn because they find it useful… You know what I mean? :slight_smile:

As for the maven repo, theres no problems with that, you’re welcome to do some packaging.

Edit: And most aaa titles based on the unreal engine somehow modify its source to implement their game, thats what i meant by modified sources.

davidcraft said:If you don't mind I am still going to look into hosting a public repository to help out others using maven when they ask. Not sure if I can do that feasibly, I will let you know

Maybe this'll help:
erlend_sh said:
Maybe this'll help:

Uh... looks like that link deals with code repositories. When I said repository I meant a maven repository not a code repository >_< Sorry for the confusion.

normen said:
Also sorry from me, but you know the next guy might find an osgi package convenient and not to mention all kinds of linux distribution formats, some would like us to use mercurial or git instead of svn because they find it useful.. You know what I mean? :)

And yes I understand ppl ask for all kinds of things, different OpenGL renderers (yes I have read up on THAT resent discussion) different code repositories, etc, and perhaps I asked completely the wrong way as to what I wanted. I understand that JMonkey is NOT a maven project. I could argue all day as to my opinions on why Maven is teh awesome, but that is pointless, those are opinions. There are plenty of equally valid opinions on why ant (or any other build system) is better, just like renderers, or code repositories. I was never trying to argue to switch JMonkey to be a maven project.

What I arguing for, and I still think is needed, is for JMonkey to be available via a maven repository. Now just because the name is a 'maven' repository doesn't make it 'maven'. It is just that maven designed it first but ant works with maven repositories fine. I know of quite a few 'ant' projects that also are available in the Maven Central Repository. Yes even ant itself is there. Most large/heavily used java projects are. It is rare I find one that is not which is why I was surprised with JMonkey. Now no I do not know the status of other similar game engines, I am fairly new to this group.

As I said, ATM getting JMonkey into Central would be hard if not downright impossible ATM. It can however be uploaded its own repo. Now there are several ways to do this. I have listed a few:

1) A third party guy like me manually uploads all the releases (and their respective libs) to some publicly available maven repository. No code changes are needed. Maintenance is low (a new upload every for a new release).

2) The same as #1 except the project team does it, and promotes the 'official' project maven repository. No code changes are needed.

3) Same as #2 except it is more automatic. At least a minimal pom (which piggy-backs off the ant script) would probably be needed (though ant MAY be able to do all this itself). With this option, there is the ability to upload nightly builds as 'SNAPSHOT's to the maven repository automatically. This makes it possible for people to continuously work on Trunk easily (change of a version number in their pom) without ever touching svn. (For example I think I may have found a couple of bugs in the picking logic, but I am not reporting it till alpha 3 as it may have been fixed, and is very hard for me to work on trunk ATM).

Now of course I would rather #3 but I would still be perfectly happy with #2. I will look into doing #1 myself if that is the best I can do, and hope that at some point I can turn it into an 'official repository' thus becoming #2.

As for the modified sources, yes I can see that happening but still that would only be one custom library (JMonkey?) while all those other libs would still be valid to grab from an official repository.

I have made my argument, the choice is of course all up to you all. I offer my services if/when you want them. I would like to contribute to this project if I can.

EDIT: BTW the libraries for JMonkey I have working with maven are not really wrapped. The original jar is used with a minimal pom file. (created automaticaly by the repository I use, Nexus.) JMonkey itself is also not wrapped in any way. All I have to do is upload the jar, fill in things like the version number (jme3.alpha2) and group id (com.jmonkeyengine), and Nexus takes care of creating a minimal pom with that info, and the directory structure automatically. It also allows you to upload javadocs and source jars for every jar. I did this with JMonkey itself but not for any of the libs. I may go back and do that as having the sources and javadocs is always nice in editors like eclipse.

I think its okay to have a maven repo with jME3. Thing is, nobody in the team has experience in maven nor the time to set it up, etc. So a third-party taking care of that would be great. If you want to do that, go ahead. I can tell you which libraries were modified and which were not, and if any changes are needed to make it more compatible I can take care of that.

Alright then I shall look into that. Yes a list of modified libraries would be great.

The biggest thing I will need to look into is where the best place to host it would be. I have always just used Nexus and put it on an internal server. I know Nifty-Gui has theirs on Source-Forge.

I will keep you all informed,


Alright, here’s the deal. While I have always used something fancy like Nexus (which runs on tomcat) this is certainly not needed. Maven can ‘deploy’ to just about any place it can write to (through like ftp, ssh, etc), and that place can become a repository if it is available for everyone to read from. I figure there are a few options.

  1. Host the repository directly on This obviously has some issues with who would have the permissions and the know-how to set it up.
  2. Do something like what Nifty-Gui did. Get like a SouceForge JMonkey account, and use that as the repository.
  3. Put the repository on some other third party site (like my own personal site/server). This has issues with stability, and puts me in sole responsibility forever.

    Let me know your thoughts. For now (when I get the time) I will work on getting publicly on my own site as at least a proof of concept.

    Also for now this all is just assuming having the release version available. I DO have some ideas about also getting nightly 'SNAPSHOT’s available as well but some of that will depend on the repositories location and a few other things. I will pursue that more once the base stuff works.


@David - have you had any success with getting maven and JME to play together? I was working from this but some of the dependencies just don’t show up in the local repository.

Have you considered:

4) - build a script to turn a snapshot zip into local maven repositories which users / organisations can install and depend upon?

I know it’s not very “maveny” but it’ll mean that when / if whoever is maintaining it wanders off the stuff can be recreated.

EDIT I automated enough of this to make the tutorials build / run on Windows. Then I added a page to the Wiki, and posted in this thread. I can’t see the post but here’s the link to the Wiki page. Since I have no (successful) experience deploying artefacts I haven’t tried to deploy. It’s enough for me that I can extract a zip file, and do a find/replace on a BAT file and have an up to date Maven snapshot of JME3.

1 Like

Sup Grigorii.

As I said said I have it ‘working’ just not automated. Some kind of script, as you suggest, is an idea I will have to look into if it does come to that and would be better than nothing.

I have not had too much time this week to look into the issue very much. Hopefully this weekend and maybe over the holidays I will have more time. I want to get a test up that will automatically deploy JMonkey somewhere as a demo to show off to some of the JMonkey Core Members/Contributes so that maybe, just maybe It can work in an official nature. My first goal would just be releases (alphas, betas, final release) but perhaps one day it can be part of their nightly build system. I can play around with putting it on my own Hudson server for that part.

But yah we will see where it goes and of course is very time dependent, whatever is left after Job + side project + Holidays lol. I will keep you all updated though.


Audacity : On

I made a wiki page with instructions how to do this …