Right. I guess I am just too tired today, so cannot think straight!
Gradle is maven without any of the bad. If you’ve never looked at gradle then you don’t have a perspective of what that means, I think.
Even aside from the BS maven dogma (that prevents you from doing simple things like including a jar file that’s not part of the maven ecosystem), gradle is just a way simpler tool to use and is more user friendly in a 100 different ways. I have to use maven for my day job and I hate it every time.
No theres not. Thats like me saying theres an inner barrier to using the SDK for you. Why would anyone use 10 different build and distribution systems? We have a build system and we have a distribution system. Now we changed the build system to gradle which also allows easy maven artifact distribution. Yet because of constant whining we had to add maven support to the already released 3.0 ANT-based project too. Maybe thats why you get an impression of a “barrier”.
We even have a build system for projects, like most similar SDK projects do. Some base these on Visual Studio, some on other build systems like CMAKE or even simple make, in the fewest cases people whine about that. In the Java world, especially “Eclipse with Maven” users are absolutely close-minded about using their buildr-based (lol) IDE and adding libraries the only way they know how to…
You can have unmanaged dependencies in maven. I do it all the time at work. It allows to use jars in your project that are not in maven central or any registry. The idea is to create a local registry in you project and declare it in your pom.
I mean if you really want to use latest JME in maven you can build it from the master branch and add it as unmanaged.
look for “maven unmanaged dependnecies”
Regardless if people prefer Maven, Gradle, Ant, Ivy, SBT or javac the point is that the libraries should be in a central repository for easy fetching.
Game development is so backwards to enterprise development it’s scary. Bottom line is that things need to be built continuously on commit and pushed to a repo, then everyone can use whatever version they like, regardless if they like to manually download the jar or use the dependency mechanism of the build tool. Everyone is happy 
3 Likes
Ahhh… I am sorry, less than anything I wanted to start a flame war… I think that the root of my problem comes from the fact that I am using the engine mostly as a library among many of other libraries, and working with build systems such as Leiningen or SBT. Really, about 95% of all required libraries are just a copy-paste-of-a-single-line-in-the-build-file away. Also, I have to develop on various machines and that approach allows for easily transferring the project from a PC to another PC, also lessening the load on the repository.
Totally agreed with DannyJo - when blaming Maven, really, I cannot imagine a much different system that would allow for a planetary centralized jar storage. And when saying “maven” I mean just that, the repository system, not the tool itself, because in reality I use either Leiningen or SBT or Gradle (recently). For me it’s just a standard that is being increasingly enforced on the planetary scale and I cannot really see anything bad in it. I also see many people turning toward it, supporting it. You always know, where to find the jar, and the jar is just a single copy-paste away… and yes, it could be something other than XML, but…
Okay, let the things happen the way they happen, I think that there is really no place for an argument, I can solve all the problems of myself for myself 
If you do professional game development you will in 90% of cases build your own adapted version of the engine anyway, making this discussion moot. As you say game development is a far cry from Java Enterprise development - we can’t publish iOS deployment via maven for example.
Well, I’d just add that I’ve uploaded the current versions of Lemur and Zay-ES to Clojars, so that them are available to Clojurians or users of any other Maven-enabled toolsets (if Clojars repo is added to the repositories): com.jme3-contribution group - Clojars
If its only about Lemur and Zay, David uploaded them to bintray a while ago.
Hmm, how can I find it there? Cannot see them…
Well great. We’ll guide anyone to you who wonders why they have outdated versions of these in two years. /facepalm
Yeah, I know. Anyone is free to disregard the message. I frankly hope that in the nearest year the contribution repo will reincarnate and there will be no need in such a thing that I did… till then I will simply be updating the artifacts once in a month, because I plan on using these libraries and keep them maintained. Also, there always will be the timestamp which can suggest anyone the possibility of the libraries being outdated in case if that happens.
Sure you will and sure people will look at the timestamp… :chimpanzee_rolleyes: Couldn’t just have made your own local repo, could you? Had to make a point from it.
Instead of clojars, can you use bintray. Mainly because :
- bintray allow each to upload artifact (as we did) and also to provide an unified view in a repository (akka contrib - Maven - Bintray) via link. then user only need to reference the unified repository and not every repo.
- bintray also allow to link to jcenter and to be accessible in maven central in few clicks (the first time) if your package (artifact) follow rules (javadoc, source, no dependencies out of maven central)
PS: @Empire_Phoenix (for JME-JFX) and I (for xbuf, and other stuff) use it.
I will try. Yes, I’ve made a local repo, but since I have to develop on various machines (depending on where I am), I have to have the thing somewhere in the internet. So I uploaded it to Clojars… maybe I could’ve skipped the announcement though…
Oh, yes, I could, found them… I just want to ask - these versions are dated Sep 25 2014, were there no updates since that time?
Like the idiot who uploaded a random prerelease version of jme to the official maven repo? Nah, its better this way, at least we know who to contact in a year when you switched to Unity, stopped developing your app, got a new job or whatever.
No, I didn’t update because :
- I don’t use them
- it’s the lastest version @pspeed published has jar into svn (see https://code.google.com/p/jmonkeyplatform-contributions/source/browse/trunk/zay-es#zay-es%2Frelease), it’s wy I included the revision number into the version of the artifact.
- I hope that @pspeed will push it’s artifact on it’s own bintray repo some day in a future
(like hosting project on github)
So if you don’t build your jars from source, you should have the same (outdated) than me.
I don’t ask you to use the artifact I pushed on bintray, but to use bintray to host artifact you push. Then it’ll be easier to know who push what and when, downloads, …
I think I can add the big SVN repo split step into multiple SVN repos preserving the history and converting to Git, so the script will be fully useable the way you want it. It is possible to use it then… I should have it done by tomorrows evening. If you will consider it is worth, we could try that. If not, then I’m just happy to have it as an excercise! 
Okay… well, currently there’s only Lemur and Zay-ES and I use them from Clojure, so I’ll do it when we separate the repo!