Official maven repo for jME3.0 stable available – please test

Hey monkeys,

as some (especially Eclipse) users seem to be uncomfortable with importing jar libraries into their projects and the situation with wild and unofficial repositories that don’t contain the correct build for jME3 is getting out of hand we now provide an official maven repository for the stable jME3 version.

The repository is available at http://updates.jmonkeyengine.org/maven/

I put together a preliminary documentation here: https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:maven

If you use maven or have the option to try it, please test the repository and the resolving of the included dependencies.

Please note that:

  • The repository doesn’t use (and isn’t supposed to use) artifacts from the maven central, all needed libraries are included in the repository
    - The source and javadoc files are not yet included in the repository, this will follow after the initial testing

Thanks to all who made this necessary.

Happy coding,
The jMonkeyEngine Team

11 Likes

wrong dependencies in http://updates.jmonkeyengine.org/maven/com/jme3/jme3-jogg/3.0.10/jme3-jogg-3.0.10.pom
joggd -> oggd

1 Like
@david.bernard.31 said: wrong dependencies in http://updates.jmonkeyengine.org/maven/com/jme3/jme3-jogg/3.0.10/jme3-jogg-3.0.10.pom joggd -> oggd

Thanks, fixed.

Thank you, maven repo much appreciated. Nightly snapshot builds would be extremely cool to have :slight_smile:

@tommi.s.e.laukkanen said: Thank you, maven repo much appreciated. Nightly snapshot builds would be extremely cool to have :)

3.1 was supposed to get a maven repo anyway, thats one of the reasons we switched to gradle as a build system, however I really really suggest not using the development version for anything where you couldn’t just build it yourself. It WILL break your projects and there is no versioning going on with the development version, so using a maven snapshot version is pretty much a guarantee for problems.

Hello

I would use stable release if it was reasonably fresh say inside 1-2 months. I would like to benefit from good work people have been putting in during last 11 months. Third party tool integration may also get quite stale in such time like say MakeHuman character imports.

If regular releases are too much work then open for all community process could be used to improve unit test coverage and regressions against physics and rendering. One could put the open regression harness to separate github project. Shiny goal in my opinion would be continuous releasing of preview snapshots.

Cheers,
Tommi

If you want to develop against 3.1 and understand the risks then that’s fine. Normen’s point is that if you do so, at the current state of 3.1, you are better of building it from source.

That way, if you do detect a regression or something breaks your code in another way then you can more easily isolate the changes that caused it and/or create a patch if desired (and create a pull request).

In it’s current stage of development, a 3.1 nightly build would kind of be all problems and no solutions… and any reported problems would already be harder to support (versus someone who realizes they are on the cutting edge and is willing to do a little more legwork to report the problem).

I’m not saying we shouldn’t have nightlies, just that they are a low priority given the relative amount of work left to do on getting them working.

@tommi.s.e.laukkanen said: Hello

I would use stable release if it was reasonably fresh say inside 1-2 months. I would like to benefit from good work people have been putting in during last 11 months. Third party tool integration may also get quite stale in such time like say MakeHuman character imports.

If regular releases are too much work then open for all community process could be used to improve unit test coverage and regressions against physics and rendering. One could put the open regression harness to separate github project. Shiny goal in my opinion would be continuous releasing of preview snapshots.

Cheers,
Tommi

What pspeed said and what would be the fix you’re missing in stable right now?

Good morning

Thank you for asking and clarifications. I am not missing fixes in 3.0 and as said it is great that stable releases can be found from maven repositories.

Regards,
Tommi

Wait a minute…
So how do you turn your Jmonkey project into a maven project with android?
As you remember, I tried to do that ealier as seen here:
http://hub.jmonkeyengine.org/forum/topic/how-to-make-a-jmonkeyengine-project-into-a-maven-project/
so should it be easier now?

@ValorZard said: Wait a minute.... So how do you turn your Jmonkey project into a maven project with android? As you remember, I tried to do that ealier as seen here: http://hub.jmonkeyengine.org/forum/topic/how-to-make-a-jmonkeyengine-project-into-a-maven-project/ so should it be easier now?

Please consult the manual of your IDE on how to create a project for different platforms.

Since i had a half day free time i tested the repository and everything seems to be fine.

1 Like

Can you host test-data in the repository ?

If you wisch, you can complete the metatdata (pom) with :

  <url>http://jmonkeyengine.org</url>
  <inceptionYear>2014</inceptionYear>
  <scm>
    <url>https://github.com/jMonkeyEngine/jmonkeyengine</url>
    <connection>scm:https://github.com/jMonkeyEngine/jmonkeyengine.git</connection>
    <developerConnection>scm:git@github.com:jMonkeyEngine/jmonkeyengine.git</developerConnection>
  </scm>
  <licenses>
    <license>
      <name>New BSD (3-clause) License</name>
      <url>https://wiki.jmonkeyengine.org/legacy/doku.php/bsd_license</url>
      <distribution>repo</distribution>                                                                  <!-- MISSING -->
    </license>
  </licenses>
  <developers>
    <developer>
      <name>Kirill Vainer</name>
      <id>Momoko_Fan</id>
    </developer>
    <developer>
      <name>Erlend Sogge Heggen</name>
      <id>erlend_sh</id>
    </developer>
    <developer>
      <name>Skye Book</name>
      <id>sbook</id>
    </developer>
    <developer>
      <name>Normen Hansen</name>
      <id>normen</id>
    </developer>
    <developer>
      <name>Ruth Kusterer</name>
      <id>zathras</id>
    </developer>
    <developer>
      <name>Rémy Bouquet</name>
      <id>nehon</id>
    </developer>
    <developer>
      <name>Paul Speed</name>
      <id>pspeed</id>
    </developer>
    <developer>
      <name>Brent Owens</name>
      <id>Sploreg</id>
    </developer>
    <developer>
      <name>Eric Potter</name>
      <id>iwgeric</id>
    </developer>
  </developers>

Mh, dunno, why? We don’t host the examples either. And they clearly are made to copy&paste, as well as the test data. Who would want to import 40MB of test data to have one texture or model? And the files are generated, giving us the content of the file isn’t necessary, thanks.

We can create and share samples using the same testdata (teapot, song, …), (no need to store them on scm).
If you thinks it’s the wrong place. I’m fine to host it on jme3stuff as the first assetpack.

2 Likes

Hi Normen and David

My 2 cents:

+1 for hosting the test-data as it is convenient when evaluating the engine using different IDE. The test data jar can be in different repository but I don’t really see the point as testing related jars should be placed to same repository and just used with <scope>test</scope>.

I faced this when testing the stable release from repository.

Its not really that handy to copy paste the test data unless it is downloadable as zip and even then just adding it as maven dependency is preferable :).

Br,
Tommi

@normen worked great for me using IntelliJ + Gradle. Hope you don’t mind I’ve updated your wiki documentation to include a Gradle section.

3 Likes

Spoke too soon – nifty throws this exception when I try to use it:

java.lang.NoClassDefFoundError: org/bushe/swing/event/EventService at com.jme3.niftygui.NiftyJmeDisplay.<init>(NiftyJmeDisplay.java:159) ~[jme3-niftygui-3.0.10.jar:na] ...application... at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:226) ~[jme3-core-3.0.10.jar:na] at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:130) ~[jme3-lwjgl-3.0.10.jar:na] at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:207) ~[jme3-lwjgl-3.0.10.jar:na] at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_20] Caused by: java.lang.ClassNotFoundException: org.bushe.swing.event.EventService at java.net.URLClassLoader$1.run(URLClassLoader.java:372) ~[na:1.8.0_20] at java.net.URLClassLoader$1.run(URLClassLoader.java:361) ~[na:1.8.0_20] at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_20] at java.net.URLClassLoader.findClass(URLClassLoader.java:360) ~[na:1.8.0_20] at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_20] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ~[na:1.8.0_20] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[na:1.8.0_20] ... 7 common frames omitted

The problem goes away if I add a dependency on ‘org.bushe:eventbus:1.4’.

1 Like

Having used the maven artifacts now for
JFX Gui building and a small seminar project for university, I can say that it works quite nice so far, and especially for the alter case saved a lot of time when building and deploying.

@normen Is there a chance to put the JogAmp backend into this repository too? Otherwise, we (JogAmp) will have to put it into our own development repository and maybe on Maven Central too.