We are not against it we just dont use it. Maven users are usually the only ones that get excited about it and want us to adapt their build system.
Edit: And btw, who switches to maven nowadays just hasn’t heard about gradle
Edit2: And if its about “just adding a pom”: We have to maintain it, we dont ask you guys to maintain our stuff, do we?
I agree with Normen here. It’s best to choose either maven or ant. Since having to maintain the two side by side can be a bit of a nightmare. You could also mix the two, as I do, but that’s also a hassle.
On a side note, there is a perfectly good example in the wiki on how to get JME3 into your local repo from the JME3 nightly build right from your own maven pom (with the help of a bit of ant). If you use this approach, you can still have JME3 in your dependency list and everything and the team doesn’t have to maintain anything maven related. Best of both worlds really.
We are the Maven. You will be assimilated. Your project will be added to our own. Resistance is futile.
Resistance = gradle. 
All of the benefits++ and none of the dogmatic pain.
Main problem:
Nobody willing to provide server space for hosting the cron.
I know the point of the jme-devs and I agree that maintaining two buil systems is a lot of work, that’s why I volunteered to do it. Without a server that’s just useless work and I’ll happily take on the task the moment we got some server space (and address the issues with the other libs we are currently providing as snapshots).
About the “Maven sucks and its users are dogmatic morons” (sarcastic hyperbole, I am just sick of these bullshit discussions) discussion:
Ok guys,
Gradle: Uses Ant, which uses Ivy for dependency resolution which in turn can hook into the Maven REPOSITORY architecture
SBT: CAN use maven poms and hooks into maven REPOSITORY architecture.
I could continue with almost any other of the currently hyped build systems.
I just don’t give a damn about what build system people are using but the REPOSITORY-layout is a well established standard in the development world.
People use it for a reason, no matter what actual build system they are using.
The Maven-archetypes we created are just the icing on the cake for people actually using maven (or a build-systems that understands the maven directory layout).
Well, as I’m using maven as well, installing a copy of the jme libs into my local repository I would be glad to have some server running these stuffs, if it can handle nightly snapshots and such…
I have a server running mainly for no special purpose but just kept it through the years. I’m willing to offer the space and tools, if someone can help me install it. (I was already thinking about starting a maven server, but got a bit confused with the setup.)
I tried Nexus Sonatype and Artifactory and I could use the latter more easily. I also tried to use apache continuum as a build system, but got lost
So if someone out there is willing to help me, I can give away enough webspace for that.
pflanzenmoerder said:
Gradle: Uses Ant, which uses Ivy for dependency resolution which in turn can hook into the Maven REPOSITORY architecture
Small pedantic correction: Gradle has access to ANT internally to call ANT tasks but has its own mapping to ivy and its own project model. ANT and AntBuilder were just convenient ways for them to get base functionality when they started but I personally never shell to ant for anything anymore. Gradle can consume and produce maven POMs but can also consume all kinds of other dependencies. It can also call maven plug-ins but I've never done that personally.
I was mainly responding to the resistance is futile thing. I truly believe that any Java developer _switching to_ maven these days (ie: they were using ant or something else before and decided to switch to maven) is missing out if they don't switch to gradle instead. And is probably a little foolish. If a team is already on maven then there is a huge sunk cost already there... switching makes less sense in that case. The project new to that model can skip much of that sunk cost with gradle.
But I agree that POMs would be useful in any case. Though not personally relevant since Mythruna is the one project in my source tree that I just build with JMP... 0 sunk cost + push button uploadable builds. Zero effort trumps 'some effort' any day when I'm spending my spare time on it. :)
1 Like
@anthyon Nice First you need to get a Sonatype account so I can give you acces rights to the repository. I will then help you get the stuff up and going (it’s just a skript that needs to be croned)
@pspeed I completely agree. I like the new breed of build systems, although I am mostly stuck with Maven (and finally Maven 3) at work. Gradle is awesome, as is SBT. We are getting a chance here to talk to one of the Grade-devs in person and I hope we could finally convince some people to switch over.
Since this thread has been quiet for a while, I will post explicit links to help newcomers and make sure we are all on the same page(s).
It looks like the snapshot jars currently in the Sonatype repo here (as of 2011-09-26) were uploaded on 2011-03-13.
https://oss.sonatype.org/content/repositories/public/com/jme3/
The latest JMonkey nightly build (regular, not Mavenized) I can see here is dated 2011-08-29
(I don’t know why these stopped a month ago; part of freezing for upcoming beta release?):
[edit: It seems nightly builds resumed appearing about 14-Oct-2011, and somehow filled in the missing back zips, so everything is groovy now!]
http://www.jmonkeyengine.com/nightly/
([Edited 2011-12-14]: Ant problems with this URL? - Change “www” to “direct” in hostname!).
I am all for the automated nightly repo uploads from anthyon’s servers, but in the meantime can
we maybe persuade pflanzenmoerder to do a single upload of jars based on the
2011-08-29 nightly, using the maven wrappers (and his Sonatype account) here?:
https://github.com/erlend-sh
Also, to help those trying to find this info, are there any objections to updating this fine wiki page of do-it-yourself instructions:
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3_maven
to include a link to a new wiki page describing the status of work on the sonatype repo and including links to:
- This forum discussion (which ranks below some older discussions in the googles)
- Sonatype directory
- The github community project.
I am happy to make these Wiki edits if noone objects. Another thing I can contribute is some current work
on deploying JME3 under OSGi (ducks to evade the moldy fruit, points towards cogchar.org).
It will be easier to share that OSGi work once there is a more up to date set of jars in the Sonatype repo.
Our OSGi bundle poms (which so far simply mark certain JME3+dependency packages as explicitly
“exported” or “private”) can be added to the github project (and eventual cron build+deploy), if the
community wants that. I mention it here because people who want maven jars and OSGi bundles tend
to have interests in common. There are more issues with actually running JME3 under
OSGi, but we can save those for another thread ;-p
2 Likes
OSGi bundles will also be provided by us when jME3 is stable. The current jME3 plugins are more or less the same and can be cross-compiled to OSGi easily. The issue with OSGi is that (like the NetBeans plugins/modules) it uses a closed classloader environment that only accounts for classes (e.g. not for the jme3 native binaries) and you thus have to care that the classes are loaded on the plugins classpath to have access to the non-class files of its classpath… However I was able to work around these issues.
And yeah, you could make those changes to the wiki.
I don’t know if @pflanzenmoerder is active. If you’d like access to the GitHub repo, please tell me your username (or request access I suppose, but let me know here as I don’t check GitHub often) and I’ll give you access.
Thanks to help from @erlend_sh, @pflanzenmoerder, and @normen, we’ve made some
progress. JME3 binaries from nightly build 2011-12-15 have been delivered to the
“snapshots” area on Sonatype, and a sample project (which just launches the JME3
TestChooser GUI) is building and running against those snapshots. See:
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3_maven_repo
http://groups.google.com/group/cogchar-users/browse_thread/thread/51cf40ac1106ec21
@stub22 said:
Thanks to help from @erlend_sh, @pflanzenmoerder, and @normen, we've made some
progress. JME3 binaries from nightly build 2011-12-15 have been delivered to the
"snapshots" area on Sonatype, and a sample project (which just launches the JME3
TestChooser GUI) is building and running against those snapshots. See:
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3_maven_repo
http://groups.google.com/group/cogchar-users/browse_thread/thread/51cf40ac1106ec21
First of all thank you guys for updating the artifacts on Sonatype. I use these artifacts in my game and yes I'm using maven (in combination with jenkins) to build my release versions. Everytime I start the game I get the following error: "Failed to find loader: com.jme3.audio.plugins.OGGLoader" (http://hub.jmonkeyengine.org/groups/general-2/forum/topic/failed-to-find-loader-com-jme3-audio-plugins-oggloader/). Maybe I miss another artifact or maybe the "JME-jogg" artifact is the one that was not uploaded to Sonatype. It would be great if in one way or the other this problem could be solved.
Thanks in advance.
The jME3-jogg jar was missing but has now been added, as discussed further in the thread Entrusc linked to.
Today I cleared the snapshots repository and then re-uploaded the 2011-12-15 snapshot, so that we now see only the current artifacts in the snapshot view. I also renamed the xmlpull artifactId to xmlpull-xpp3, thus matching the jar name provided by jME3 nightly build.
Index of /repositories/snapshots/com/jme3
(Before today, there was a hodgepodge of old and new stuff in the snapshots view. You can still see the old directory names [but no old jar files] through the “public” repository view).
I committed my revised version of the upload_jme3_to_sonatype.sh script to the jme3-maven project on github, with some accompanying README files:
GitHub - erlend-sh/jme3-maven: An unofficial branch for jME3 maven hosting. Supported by the jMonkey community.
The accompanying archetype and demo files in that github project are now out of date. For the time being, a new maven user’s best bet is to use the little org.friendularity.demo.jme3.maven project as a starting point, and chop out the dependencies you don’t need (e.g. on jME3-testdata).
The pom.xml file of this demo project has been updated to use the xmlpull-xpp3 artifactId. I also divided the dependencies into sections, and [edit - just now] added commentary at the top.
1 Like
It looks a newer version of JME than the one currently on sonata is required to the the terrain tutorial. Am I stuck to go back to the “old” way of having the ant script to download nightly jme? I don’t mind having an out of date JME, it’s just that I was very interested in finishing the Terrain tutorial. (It’s the only one that I have left )
The current version in Maven Central (hosted by Sonatype) is still based on the JME3 nightly build of 2011-12-15. I am planning to have an updated snapshot in place within one week, before 2012-02-10. I will post another message to this thread when the update is done.
1 Like
That would be awesome! Thank you!
I’m also looking forward to this maven update, thanks for the effort
An updated snapshot is now posted, based on the JME3 nightly build of 2012-02-09.
For example, here is the core library:
Index of /repositories/public/com/jme3/jME3-core/3.0.0.20120209-SNAPSHOT
Changes from the last snapshot:
- I embedded a datestamp into the version, so your dependencies will now need to include a version marker, like so:
3.0.0.20120209-SNAPSHOT
(It’s easiest to just put that text into a property, and re-use it for all your JME3 dependencies).
- The “noise” library is no longer part of the JME3 download, and hence, no longer part of the Sonatype snapshot.
I will probably manually delete the old 3.0.0-SNAPSHOT from December 2011, to prevent confusion. I’m planning to
to do that about Feb 16, one week from today. Going forward, all the snapshots will have datestamps.
Please note: We do not have control over how long Sonatype will keep a particular snapshot build available
(while “release”-s are available forever, generating them requires some extra mojo). However,
based on experience, we should be able to keep several of the “most recent” snapshots available for
several months.
2 Likes