Unfortunately the reason these things aren't done yet is that they aren't the most fun of things to do. However, I agree they must be done before we can call this 1.0.
I would like to add that I think it necessary for us devs to agree upon an idea of multithreading support that jME intends to support and handle it. Ideally that would be mean complete thread-safety for jME, but that may not be plausible for the next release. Another option might be to add JavaDocs and wiki entries for every jME call that must be executed in the OpenGL thread and/or is not thread-safe.
Lots of documentation chores… I think 3 and 4, which I assume includes removing all currently deprecated methods/classes,are the only true coding tasks on the list. I agree though, all necessary items. I would love for 1.0 to follow .11 in fairly short order (3 months max maybe?) specifically because we aren't offering any new features. I'm a bit pessimistic about the likelyhood of us doing all of them anytime soon though because none are fun. 
My personal feeling is that the wiki really needs to be on the list as a high priority item. Our feature list should be up there with links to related jmetests, or some sample code. We should make it more fleshed out and encourage active participation in using the wiki as a primary source of knowledge.
As to the multi-threading topic, I also agree that documenting is the way to go for 1.0. Rather than simply making what we have thread safe I'd personally like to see renderer and display system broken out into self-contained systems that are thread safe, non-singleton and can run concurrently wherever possible. allowing for multi-display support as well as simulation loops that do not include time for rendering (they send data to the renderer and forget about it, allowing the renderer to render later when it is ready, etc.)
Random thoughts I suppose.
I would love for 1.0 to follow .11 in fairly short order (3 months max maybe?)
That seems a bit optimistic to me, while there won't be any new features going in, this is not a small amount of work that needs to get done. Add in the fact that getting everyone to do it in a timely matter because it is so "unfun" is going to be difficult.
I agree that the wiki should be one of the major tasks (the User's Manual especially).
This would really be wasted time imo. Unit tests should not test methods but units! Testing single methods is way too fine grained. But having at least one test for each class (if it's not a little helper/data class) would really make sense.
agree, I was getting a little overzealous. :)
I also feel that there are some coding/redesign that needs to be done. Shader system is a mess, the model loading system needs to be unified (loading different types of models occurs in different ways), etc.
mojomonk said:
I would love for 1.0 to follow .11 in fairly short order (3 months max maybe?)
That seems a bit optimistic to me, while there won't be any new features going in, this is not a small amount of work that needs to get done. Add in the fact that getting everyone to do it in a timely matter because it is so "unfun" is going to be difficult.
If there will be new features, such as what you are saying about cleaned up shader and model handling, then I'm in no rush. I would just hate for us to release 1.0 a year from now (exaggerating here) with nothing significant added.
In that same vein, I'd like to see us clean up resource handling, specifically how jME *finds* resources. For example, registering locations for textures in priority order and then allowing the user to just ask for a texture by filename. We could do the same for models, especially with a more unified approach to that in the offing.
maybe then we could find a better solution to the standard texturemanager.loadtexture(XXXClass.class.getclassloader().getresource("monkey")) which returns null if it can't find the resource and thus, doesnt give texturemanager any chance of telling what file it didnt find
I actually agree with Renanse (I know…I'm shocked!) that we need to decide whether we want to shoot for 1.0 in a relatively short turn-around or not do a feature lock. One of the aspects of jME that I think keeps people really active with it is the fact that new things are constantly being added. I just don't want to do like Renanse suggests and take forever to get 1.0 and nothing new really comes with it except some JavaDocs, a few efficiencies, and a guarantee of stability. :o
I would suggest we make strides towards getting all the documentation and cleanup done along-side adding new features and then when we believe we're pretty close to being done we release .12 and at that time do a feature-lock and work on finding any residual bugs, cleanup, etc.
Perhaps set a goal of what must be accomplished (as far as the "non-fun" stuff) before we can release .12 and then have a game plan for the 1.0 release. This gives us the ability to continue to add features and then provide a short turn-around between .12 and 1.0.
…but you guys know me, I rant a lot so take it for what it's worth. 
I think if we can coordinate amongst ourselves well enough, having 1.0rc1 out by the end of summer or there abouts would not be out of the question. By coordinate I mean setup task lists, designate heads and backup heads for certain task areas, maybe figure out some kind of incentive system, etc. By "release candidate 1" I mean fulfill the tasks we've laid out above sans major testing. We could then iterate on testing and have "1.0 final" out by year's end.
Pulling from the above lists it seems like we have the following major task areas:
- In Code documentation (javadoc, inline comments, etc.)
- Out of Code documentation (wiki, user manual, website)
- Code cleanup (general standardization - 1.5 conventions, method names, public/private access, etc. - trimming or moving deprecated/non-ideal code)
- Logging (Could be part of #3, but I think this deserves its own area)
- Asset management (cleanup how jME finds and loads assets such as models, textures, shader code, etc.)
- Unit/Regression testing
- Shaders?
As much as possible I think we should recruit people from the community to help with items in the above list, especially for #2. That aside though, if the above list looks generally inclusive of everyone's thoughts, are there particular areas we are each interested in spearheading?
Personally I find #5 the most interesting mostly because I wish texture finding/loading was handled better from long ago, but if someone else would like it I could go for something else.
I would be happy to do work on both #3 and #4 but also am willing to help with anything else as necessary.
I vote Irrisor handles the Unit tests since he's so in love with them.
darkfrog said:
I vote Irrisor handles the Unit tests since he's so in love with them. ;)
hehe
i'd take any point, but #1, #3 and #7 would be ok. #7 is close to my heart, and #1 we will need to be many doing…
I agree, I think #1 is going to just need to be divided amongst us by packages to deal with.
I agree with the priorities. What I'll start doing at work is spend some time first thing in the morning commenting/cleaning a random class here and there. If others start doing something similar that will get the ball rolling until we get it a bit more organized.
My steps will be:
- Read existing comments (fix grammar/spelling, see if they still are accurate, etc).
- Add missing comments
- Look for code that can be cleaned up with 1.5 conventions.
- Do other general clean-up (reuse opportunties, consistency, etc)
Once we get everything organized, I'll switch to whichever method we decide on, but until then, some work will get done.
Sounds like a good approach to #1 and #3. Perhaps you could spearhead those efforts? (i.e. more guidelines like the ones you wrote above, whipping us for checking in undocumented code, etc. )
If so, our list could look like:
1&3 - Mojo
2 - Llama or a community member(s) like Doug Daniels or Gentleman Hal
4 - Darkfrog
5 - Renanse
6 - Irrisor
7 - MrCoder
If that's good, I suggest starting a thread in this board for each bullet to discuss approach, such as best approach to systemic asset locating, or logging.
darkfrog said:
On my side I haven't really even been able to touch jME (or anything game dev related) lately. :P
dito :|
i'm almost finished with rewriting the shader system(inside the 1.0 restrictions), just need a few more tests, so probably a checkin this weekend…i've checked in some minor javadoc additions but i'll get back fully on that after the shader checkin…
Any updates here?
On my side I haven't really even been able to touch jME (or anything game dev related) lately. I'm hoping after this weekend I'll be able to move back towards game development, but jSeamless is kicking my butt. 
Oh look at MrCoder, just trying to make the rest of us look bad.
…I wanted to say "Great job!", but felt it was necessary to push you down before I could feel comfortable building you up.
Great job!
Where's the teacher? I would like to give him an apple s
Just want the 1.0 to get out so we can start doing some really great changes
(do you really need me to make you look bad froggy? XD)
MrCoder said:
(do you really need me to make you look bad froggy? XD)
No, I'm quite skillful at accomplishing that myself. Such is why you should leave that effort to me instead of taking matters into your own hands. ;)