MrCoder and I will be making a big push this week to finish up as much of the remaining jME 1.0 tasks. As a reminder, our old list was:
1. In Code documentation (javadoc, inline comments, etc.)
2. Out of Code documentation (wiki, user manual, website)
3. Code cleanup (general standardization - 1.5 conventions, method names, public/private access, etc. - trimming or moving deprecated/non-ideal code)
4. Logging (Could be part of #3, but I think this deserves its own area)
5. Asset management (cleanup how jME finds and loads assets such as models, textures, shader code, etc.)
6. Unit/Regression testing
7. Shaders
Of these, MrCoder has taken care of 4 and 7 (he may have a few things to commit for #7 still) and I will be ready with #5 tomorrow or Wednesday.
Removing sun-set code (JmeBinaryReader/Writer, jmex.sound, others?), adding a few more unit tests, and writing more documentation is where we wanted to focus the rest of our efforts. If any of the other devs want to help finish these tasks, it would be appreciated! In fact, specifically with doing javadoc, if you can help, claim a section of code (e.g. com.jme.util.geom.*) and get to work on it.
The reason we are pushing on this so hard is because of some fairly large refactoring we are thinking of. Specifically, refactoring batches back into geometry and adding support for interleaved arrays. Also, adding enums and other syntactical sugar. I will start another posting to discuss those.
Yeah baby! Really looking forward to having a new playground after 1.0, where we can take jME to new heights for a 2.0.
How about removing deprecated methods for 1.0?
Javadocing help would be really appreciated, as well as going through the code and locating places that need cleanup.
I guess we should go through the buglist as well…
I will start out with creating some unit tests and javadoc as I go(reporting here what packages i take on). Also gonna check in some fixes and additions to the shaderstuff today.
I would suggest leaving deprecated methods and removing them for 2.0 so anyone currently relying on them doesn't have to make major changes to their code to get 1.0 functional. People will expect that moving to 2.0 will break their code horribly. 
If they are already deprecated, then they are being warned every time they compile. I don't really see a reason not to remove things already deprecated in the last release.
I've completed the utility classes for #5, providing a system that allows you to register URI locations to look for specific resource types. It even handles format changes.
As an example:
try {
MultiFormatResourceLocator loc2 = new MultiFormatResourceLocator(ResourceLocatorTool.class.getResource("/jmetest/data/images/"), ".jpg", ".png", ".tga");
ResourceLocatorTool.addResourceLocator(ResourceLocatorTool.TYPE_TEXTURE, loc2);
} catch (URISyntaxException e) {
e.printStackTrace();
}
URL u = ResourceLocatorTool.locateResource(ResourceLocatorTool.TYPE_TEXTURE, "/model/FieldstoneSpec.gif");
System.err.println("FOUND URL: "+u);
This prints:
FOUND URL: file:/C:/data/blight/dev/jslack/extern/java/jme/build/jmetest/data/images/FieldstoneSpec.png
It found this file by chopping /model/FieldstoneSpec.gif down, directory by directory and appending it to the baseURL setup in the supplied ResourceLocator. MultiFormatResourceLocator also tries finding the file using the different file extensions supplied, in the order supplied. (It will also look using the extension supplied, and you can specify whether that should be done first or when you've exhausted the extensions list.)
You can have as many ResourceLocators registered per resource type as you like. It will go through them in the order you add them and stop when it finds the first openable file. If no hits are found, or you do not have locators registered for the given resource type, it will return ResourceLocatorTool.class.getResource(resourceName) as a last resort.
My plan is to set using the ResourceLocatorTool (RLT) up as default in TextureManager when you are supplying a String argument. I also plan to set this as what all model loaders use when they parse a texture name. Doing this should make model loading "just work" a lot more often, requiring at most adding a resourcelocator that points to your texture directory.
As you might suspect, the RLT can be used in other places in the code besides textures as well. Using it throughout your code can also allow you to repoint your asset directories very simply without having to recompile (if you dynamically generate your RLs) or alter your asset files.
Anyhow, I hope you guys find this useful. I hope to have the changes into CVS by tomorrow.
Definitely useful, indeed. Still, the .jme files should not contain absolute path (like /home/username/and/so/on), should they?
I don't think they should.
They certainly do not need to, but now it wouldn't matter as much since all of the paths will be treated as relative to the paths given to the RLs.
Also, I forgot to mention that another way to use this system is for changing levels of texture size. You could setup folders for high/medium/low textures and when the user changes their prefs, you could dump your textures (or a portion of them), repoint your RL and then (assuming I do my job right in TextureManager) allow the textures to reload from the new location without touching a single TextureState or model.
