Ok, after a few months of pure hell, I’m going to be back soon (after this week both work and school slow down). The first thing I am going to do when I start up again is break eveyone’s code. I try to do good here.
In all seriousness-ish, I am going to split how jME is packaged. Better define “What is jME”, how it’s distributed, etc. This is going to jump start the 0.9 effort again. Specifically, I am going to yank out all code that doesn’t have to do with rendering a scenegraph. That’s in essence is what defines jME, and therefore, that’s what jME will be.
Everything else: Model loading, effects, terrain, particles, sound, ui, etc, etc will be taken out. These will become part of the extended jME modules set, and get their own jar. These will be com.jmex.* libraries. You may have already worked with one such library, the physics.
Reasons for this are many, and not totally arbitrary. First, it will allow us to keep the core API as clean as possible. The jME jar should be the most reliable part of this library, and keeping it small and clean will help insure this. Having all the other sections seperated will improve modularity. You may distribute as much or as little as you wish now, instead of (what was becoming) a single large jar file. You can now swap out sections much easier (For instance, the different UI features). It will also give us further options in the future for commercial options.
Therefore, all those using CVS will have to fix all their import statements. No other changes should be required.
Just a heads up, these changes will probably occur sometime late next week, to the week after that.
Looks like the physics is ahead of the pack again! 
Hehe, get it? Pack…packaging? ah well, tough crowed around here!
DP
That’s great. Welcome back.
Sounds great. Any hope of removing all those empty folders?
Unfortunately, Sun has control of the CVS server (not allowing me to directly delete folders), and moving these things will create MORE empty folders. So, that issue is going to be even worse.
I’ll start repackaging everything today.
This means I am going to move (for example): com.jme.sound.* to com.jmex.sound.*. And update the build.xml file to contain a “sound” target that will build the sound jar.
So, if you are a dev and you have some code checked out, you might want to check it in now.
Could you list the exact changes when you’re done?
yes
Will the current/old UI still be available? E.g. com.jmex.oui.*
Almost done, packages now are sepearated: core, effects, model, sound, terrain and ui.
Couple classes that are part of the core but reference external packages need to be cleaned up. Need to update build.xml and it should be ready.
Per, the com.jmex.ui.* is the old ui. You’ll have to ask Guurk if he is planning on replacing that with his new UI.
And see, I figured that’d be up to you. For sanity’s sake I’d like to put the new stuff into a different package, thus allowing for things that use the old to continue working. I was thinking com.jmex.nui., but if you believe it makes more sense to use com.jmex.oui. for the old and com.jmex.ui for the new that’s fine too.
Waiting for your lead…
From what I’ve gathered it seems like the new one completely eclipses the old one. And because only the new one is being maintained, I think it would be better if it took the place in com.jmex.ui so newbies would start by looking into that one instead of the old one.
Right, one GUI should be enough for everyone … 
not to mention also axing the .widget stuff
This is mostly done, need to test a few things (a couple classes required me to split them into subclasses to remove dependancies between packages), and do the build.xml file. This would have been finished much sooner but I’m cursed with a strong addiction to Guild Wars.
Hey mojo, I also play that addicting game!!!
Cool, I’m Ralph the Greasy, say hi if you see me (although our time difference will probably make that rare).
Almost finish, one more dependancy to remove between packages and I’ll be done. This last one is a tough one though.
Ok, the new package heirarchy is in. This is a major change, so will probably look very scary. However, much of it is nothing more than files moving around.
Here’s the changes:
removed:
com.jme.effects.
com.jme.scene.model.
com.jme.sound.
com.jme.terrain.
com.jme.ui.
some animation classes also moved (joint and keyframe)
added:
com.jmex.effects.
com.jmex.scene.model.
com.jmex.sound.
com.jmex.terrain.
com.jmex.ui.
build.xml now builds seperate jars for all of these. The targets are:
dist-core dist-effects dist-terrain dist-model dist-sound dist-ui dist-all
where dist-all builds all the jars.
There is a change with CloneCreator. If you want to Clone a model, there is now ModelCloneCreator in the model distribution.
That should be the extent of the changes. You should simply be able to download the latest CVS and change your imports and continue on.
One thing that still bothers me is JmeBinaryReader and JmeBinaryWriter reference terrain. This means Model depends on Terrain. I didn’t see a quick fix for this without refactoring the entire class. I didn’t want to step on Cep’s toes, so Cep, if you want to take a look at that, I’d be glad.
Let me know if you have any problems, and let me know if you don’t agree with a change. Did you move something that should be in the core? Did I not move something that shouldn’t be? Let me know.
Hello
buildtest.xml does not work for me atm
<target name="compile" depends="init" description="generate jme test classes">
<javac srcdir="${src}/jmetest"
destdir="${class}"
classpath="${seg}/target/jme.jar:${seg}/lib/lwjgl.jar:${seg}/lib/lwjgl_fmod3.jar:${seg}/lib/jogg-0.0.5.jar:${seg}/lib/jorbis-0.0.12.jar"
/>
<!-- copy the resources into the build directory -->
<copy todir="${jmepackage}/data">
<fileset dir="${src}/jmetest/data"/>
</copy>
</target>
i think the various new module - jars should be listed too (after jme.jar there should be jme-sound.jar, ... )
Shoot, forgot to commit the buildtest.xml file. I’ll do that as soon as I get home from work. Sorry about that.