Thank you! It does appear to be working perfectly!
Although it’s fine that we might not have the snapshot for more than a couple months. Is there any other solution? I’m pretty new to maven but I wouldn’t mind trying something else out if it more of “the maven way” of doing things.
A couple weeks back I posted a new Maven snapshot based on the 2012-05-12 (May 12) nightly build of JME3.
The new version ID is:
3.0.0.20120512-SNAPSHOT
1 Like
Hmm… I might be able to donate some server space for a repository. That would give better control over snapshot retention and anything else that might be helpful to tweak.
Questions that come to my mind:
How much work would setting up a Maven repository on a Linux box be?
How much space would such a repo with jme3 take up? (I guess it would be a per-snapshot figure.)
I’m also considering setting up a script to do nightly snapshots, but that’s the second step and needs feedback from the devs so any changes in bundled dependencies are going to be reflected properly.
Just uploaded a new Maven snapshot based on the 2012-12-20 (December 20, 2012) nightly build of JME3…
The new version ID is: 3.0.0.20121220-SNAPSHOT
The set of base jar names did not change from the previous snapshot of May 12. Yay!
Note that some of the Cinematic classes were removed/renamed in the June/July timeframe, and this is the first sonatype snapshot conatining those changes.
I’m sure there’s many other important changes in JME3 since May, but the Cinematic seems to be the only ones that briefly broke my own application build. YMMV!
3 Likes
Cinematic seems to be the only ones that briefly broke my own application buildmight be my doing :D
@stub22, is it possible to automate the snapshotting process?
@sbook It’s sort of possible. But, there are some issues we’d have to confront.
If the structure of the nightly build jar changes, then we have to update the upload script.
Sonatype will only keep a few SNAPSHOT releases for us. So if we auto-upload some
bad ones (because the nightly-build jar is bad for a few weeks, or changes in some
unexpected way), we risk losing the existing ones to Sonatype’s auto-purge. So then
we could get into a state where we have no good snapshots, which would be worse
than where we are today.
I think a better use of time for any eager beavers would be in preparing to make permanent “full releases” (as
opposed to “snapshot releases”) of JME3 to Sonatype. That will require supplying signed jars and javadocs,
which goes beyond what the crude upload script is currently doing. I think we will need either a fancier
custom script, or a pom-based build (or a script that generates a pom.xml, or some other creative solution).
I’m not very into using maven with jME since I use the SDK so I haven’t tried yet for jME but I think the best solution is to use Home | Apache Ivy ™ to handle ant->to maven interop.
In the long run I think jmonekyengine.com could host their own instance of nexus maven repo for snapshots. It isn’t very hard to set up. Also there seems to be a slow-but-gaining-momentum in the Netbeans community to move to maven. So it might be a good thing to start looking into that after 3.0 has been released.
Wasnt there some maven script that actually pulled the stuff from svn instead of relying on a pre-packaged engine? Its not as many as I have feared but we have the occasional oddball with an eclipse/maven setup coming with the strangest issues and super-old engine code.
@jmaasing, Maven definitely seems to be picking up steam in the NB world… The place I’ve really noticed it is since I’ve been working with JBoss, they’re huge on Maven and its an extremely effective. Not needing to check a bunch of JARs into source control or synchronize a /home/skyebook/libs folder across my dev machines is awesome 
@sbook Yeah I also think that using a maven (or ivy) repository is the only serious way to handle binary dependencies.
Actually getting the engine JARs into a maven repo wouldn’t be much of a problem using Ivy. It is Ant based and can publish to maven repositories. You don’t even need nexus or anything like that to set up a maven repo for snapshots. Just an apache and some means of copying files is enough.
The harder part would be to get the SDK mavenized. I’m slowly (can’t spend more than a couple of hours/month) building a NB-based application using the NB-maven-templates. It’s working rather well the little I’ve done. So it is for sure doable if we want to. OTOH it would be possible to build the SDK using ant but instead of building the engine jars at the same time the SDK-build could download them from a maven repo. In effect decoupling the release of the engine and the SDK.
It’s more a matter of what the community wants than what is possible
Using Ivy to manage dependencies is very simple, really! Since most of the more famous java libs are already registered in some maven instance it’s not too unlikely to get all dependencies from the web. And since building an Ivy repository is simple, too, I accomplished to even have my personal/uncommon dependencies available via Ivy so my repositories don’t contain any binary dependencies anymore yippie
How such an Ivy repository may look like can you see here - it’s my “personal” repo that contains everything I need not found elsewhere in the web in a maven instance.
Than I have an extended ivysettings.xml which let’s Ivy know about this (and the Nifty-GUI maven repo directly from sourceforge):
@stub22 said: A couple weeks back I posted a new Maven snapshot based on the 2012-05-12 (May 12) nightly build of JME3. The new version ID is: 3.0.0.20120512-SNAPSHOT
Hey stub22, you like to upload a new Version from the Nightly Builds? Thanks alot in advance!
Or someone else who know how to…?
I have absolutly no Idea how to upload a nightly-build-jar pack to the Nexus Repository Manager to make it in maven work like the other versions that are already there…
Would help me, and my Project alooooooot. Or link at least one or two hints how to…?
Greetings,
Philip
@jmaasing said:You don't even need nexus or anything like that to set up a maven repo for snapshots. Just an apache and some means of copying files is enough.
The Maven guys seriously recommend against that.
They say that setting up Nexus is easy, and doing it by hand is going to be pain with no gain.
I don’t know whether they’re right, but I’d recommend sticking with the beaten path.
It's more a matter of what the community wants than what is possible :)
I’m using the engine as a library in a project built with Maven. (No SDK.)
Having the jME3 engine in a maven repo would simplify my builds considerably, so I’d be all for it.
I just updated the Sonatype binary maven repository snapshot of JME3, using the 2014-03-25 stable build downloaded from JME3 website.
Also updated some of the relevant wiki pages, such as:
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3_maven
Note that my team also exports some mavenized OSGi bundles for these JME3 packages through our social robot character project stack at:
2 Likes
Thanks so much for the effort!!!
Ever since I’ve started playing around with JMonkey I was wondering why the hell there is no way to just use JMonkey with a standard build tool, where I can just type in my dependency and voila… (and if I want to upgrade, hey, just adjust the version number, build again and I have the new version)
Rejecting the great Java build eco system is kind of the same as moving from C++ to Java and not using the Garbage Collector 
Or not using the great IDE support but program in a text editor… You can do it, but it’s kind of killing the point of moving to Java then…
Something that would be really cool though, would be to have the sources published with the binaries, too. Cause then it would also be possible to use IDE support to just automatically download the appropriate sources to view during development… (same holds for Javadoc as well, I guess)
Is there any special reason to deploy just the binaries? (Besides the necessity to update the deploy script and pack the sources?)
I dont think supporting a wide array of IDEs is really a goal of the project. a lot of time has clearly been spent by the developers in modifying netbeans to make it easier to get going with a jmonkey application. It’s literally a 1 click install and your done and comes with everything you need and more.
Something as silly as an IDE preference doesnt seem worth it to duplicate all that work.