I need to integrate jme into a maven-based project, and need to mavenize the engine anyway, so I thought I could publish the results as well. Also, I finally got enough of a grip on maven and its features that I feel confident that I can do this.
I need some feedback to make it useful beyond my own project though, so here goes:
I’m seeing several jars during the build process, e.g. jME3-joal.jar etc.
I can integrate everything into a single jar, or I can keep the jars separate so any project can use just those jars that are relevant to it. (I can imagine some people using jogl and others lwjgl, some need to import blender models and others don’t, etc.).
To keep the jars separate, I need to know which jars depend on which other ones (one of maven’s more useful features is that it will automatically pull in dependencies, recursively, but this requires explicit dependency configuration).
I have extracted dependency information via jboss tattletale, but I’m not sure that it is complete; is there some dependency information available on the website itself?
Other question: I’m missing the sources for several jars that are just delivered as is.
These are (at least) jbullet.jar, vecmath.jar, j-ogg-d.jar, lwjgl.jar, stack-alloc.jar, asm-all-3.1.jar, and noise-0.0.1-SNAPSHOT.jar.
Is there a list where these libraries were originally from, what versions were used (okay, for asm and noise it’s in the jar name)?
I need to hunt all of them down, see under what name they have already been made available, and what of the available versions were used in jme.
Ouch, that’s bad news.
Finding the matching sources for a lib is going to be really hard. I wanted to have these for debugging, for example.
Are the noise-0.0.1-SNAPSHOT sources even available anywhere? I couldn’t find anything on the net or in the jme3 sources.
I did find a noise-0.0.8 on projectsforge.org. I don’t know what that projectsforge.org thing is, but it does have a list of library versions at the end of https://projectsforge.org/projects/bundles/browser/trunk/pom.xml (most likely not what’s in jme3, but what worked for them).
Nope. All these small things are why we would like to manage putting up repositories instead of leaving that to others. But we are not ready to do that yet.
I’ll use the binaries then… and alternate configurations for those libs where upstream-provided bug fixes and sources happen to give me more value than jme3-provided bug testing guarantees.
in Structure of jMonkeyEngine3 JARs: dist/lib/jME3-jbullet.jar: nifty-style-black.jar is required unless you provide your own style. I think this should be mentioned, people trying to trim down their install will hit this. dist/lib/jME3-jbullet.jar: Tattletale reports that it needs asm-all-3.1 via stack-alloc.jar.
In Plugins and Extra packages: src/ogre is mentioned twice, this seems duplicate.
The build script of the engine actually shows best what depends on what, what parts of the engine are self-contained etc. That file is only part of it. If you want to understand jme and how it builds you have to understand the build script.
Yep, I have edited the wiki in the past, in cases where I was 100% sure.
I just wasn’t sure whether there’s more to it, so I preferred asking over going ahead.
I have corrected the asm-all name, and explained a bit about nifty-style-black. Feel free to revert if inappropriate.
Yeah, actually we want to remove all version numbers from the jar files but as we’ll kick jbullet out as soon as possible in favor of native bullet I guess we won’t get to having another version of this in core. The jar naming is a really ugly part of the maven-style imo, why store the info twice if you already got description files?
I did revert the nifty jar addition though, as nifty does not depend on a style jar.
Yeah, I’ve got a task somewhere to remove HeroDex’s dependency on nifty style black. It’s only used for about 3 controls but I have the whole jar there.
For the library list I literally meant just that. Open an application, go to the libraries section, right click->add library. You get a list of libraries set up. Each of those is actually a group of jars.
The jars in each group are dependent on each other. Most of them are dependent on the core jars…but between groups there aren’t really any dependencies.
@zarch said:
Yeah, I've got a task somewhere to remove HeroDex's dependency on nifty style black. It's only used for about 3 controls but I have the whole jar there.
For the library list I literally meant just that. Open an application, go to the libraries section, right click->add library. You get a list of libraries set up. Each of those is actually a group of jars.
The jars in each group are dependent on each other. Most of them are dependent on the core jars…but between groups there aren’t really any dependencies.
The nifty style and code libs should be separate library entries in RC2?
Nifty does depend on having a style definition. nifty-style-black.jar happens to satisfy that dependency.
Not sure how to best write that up then. Right now, it’s a bit misleading since it indicates that you can simply remove nifty-style-black.jar.
I’m not sure that the version numbers in the jars are such a problem.
Yes they’re ugly, but on the other hand, extracting the version number from the jar is really much more of a hassle. Whenever I did anything version-related, whether it’s finding the sources, checking with the bug tracker, checking for version conflicts when integrating another library that uses the same jars: having the version number right on the file name has been making things for me far easier.
Here’s my current status for finding out the versions:
Nifty for example is wrong, we have a special build, same for jbullet, lwjgl-debug isn’t used at all. And no, nifty does not depend on a style jar. …Or as much as jme depends on the test assets. Again, I think this is futile but from what I read from you my impression is that you have to smash your head to a wall to see it, so I guess you will still try to.
Really its not tracked apart from that.