Issue Tracking

It’s about time we all started using Issue tracking for each element. I have been using the one at jme.dev.java.net, but not making full use of it. 0.5 is the next release. My major concern is getting model loading and animation in. Could each developer check in with what he wants to get done for the next release? I’ll then add those as tasks to the tracker.



Once the tasks are up, make sure you use it to let people know the status of the task. Also, if you find a bug that’s not a quick simple fix, go ahead and create a defect on the tracker.



Don’t worry about getting anything major done for 0.5. For instance, Gregg you initial check-in for the GUI is plenty. Dark Prophet, you will probably have the intial particle engine ready and that will be fine. Arman, you have the sound graph. So, you three just let me know what specifics you want done before the next release goes out. Eric, let me know what you are interested in tackling. There are still untouched items, such as physics, AI, network, etc. Or you are free to make improvements to the core like you have been.

As I’ve mentioned before, I’m interested in rewriting the com.jme.app package. It’s issue 89 on dev.java.net. From my description:



“Involves changing AbstractGame to an interface, and then providing implementations of various main loop types. Perhaps one “standard” much like the current version, and then some others incorporating fixed frame rate/logic rate ideas. That’ll give users some flexibility with main loop creation, and saves them the trouble of doing it themselves if they dislike the standard implementation.

AbstractGame’s signature will not change in anyway, so existing components will not have to be modified.”



With the issue tracker, would you mind adding more subcomponents? It feels rather strange to file my task under the “graphical subsystem”. Maybe consider adding “Core” and “UI”?

I’ll add them now.

Um. In retrospect, perhaps changing AbstractGame to an interface wasn’t such a good idea after all. Instead, an inheritance structure something more like AbstractGame → SimpleGame → MyGame might work out better. The only problem with this is that all references to AbstractGame must now be changed. A rather drastic change, I realize.



Given this fact, would you still mind if I went ahead with the changes? I’d certainly run them past you prior to committing to CVS. I’d also create a test JAR also so people could make sure things were working before uploading to CVS.


  • Eric (extremely glad for Eclipse’s refactoring tools)

Experiment away! I have no problem with big changes as long as they are for the better. Go ahead and give your changes a shot and see if they work out. I’ll then take a look at them when you are finished and we can discuss whether to do it or not.