JOODE Project Structure

[hdietrich]

I suggest that we will do a cleanup of the JOODE project structure. Right now we have some kind of mess in the src directory, where the JOODE code is mixed up with test classes and code that is known not to be working completely. Additionally I think there are too many packages containing only two classes. I think we should aggregate some of them.

My proposal:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21

+ src     + java            the pure JOODE source code         + net.java.dev.joode             + collision       collision stuff             + geom         geometry classes             + joint         joint implementations             + space         space classes             + stepper         stepper interface + implementations             + util         utility classes (check what is needed and what is obsolete)             Body.java             Mass.java             World.java             WorldObject.java     + test         + net.java.dev.joode      put here all the test classes     + samples            put here some sample applications and tutorial code + contrib            this is a place where everyone can contribute code and documentation (give write access to anonymous user) + doc               the project documentation + lib               external libraries + build               directories used for builds + dist               packages for distribution (joode.jar, joode-src.jar, joode-api.jar, etc.)

Additionally we should think about how far we would like to integrate the Xith Binding into the JOODE source code, and if we want to add bindings for other rendering frameworks (e.g. Java3D or JME). Maybe we should add an additional package for that.

Tell me please what's your opinion about a restructuring of the project.

[Amos Wenger]

I think it's good.
But for the .jar files, I suggest having :
joode.jar
joode-test.jar
joode-xith3d.jar
(joode-jme.jar)

[hdietrich]

I think it's good.
But for the .jar files, I suggest having :
joode.jar
joode-test.jar
joode-xith3d.jar
(joode-jme.jar)

That are just examples to demonstrate the usage of this folder.

Games published by our own members! Check 'em out!

[arne]

I think, it would be better, if the testcases would also be structured, like they are now:
net.java.dev.joode.test.joints
net.java.dev.joode.test.collision
net.java.dev.joode.test.space

else it looks pretty ok - maybe only the collision stuff could be splitted up more (e.g. for all this Convex-Hull collision code, and the collider-implementations itself should go in a seperate package)

[hdietrich]

I think, it would be better, if the testcases would also be structured, like they are now:
net.java.dev.joode.test.joints
net.java.dev.joode.test.collision
net.java.dev.joode.test.space

else it looks pretty ok - maybe only the collision stuff could be splitted up more (e.g. for all this Convex-Hull collision code, and the collider-implementations itself should go in a seperate package)

I agree, the testcases should have the same structure like the src packages. More subpackages are OK as well, as long as we will aggregate a centain functionality there, that consists out more than one or two classes.

Where I am not quite sure is what are tests and what are samples. On the one hand most of the code in the test package right now are moreover visual tests than unit tests. On the other hand they are nice samples as well 

I would suggest that we will put only real testcases (unit tests) in the test folder and all "tests" that have a presentation will go to the samples folder.

[arne]

I think, all those Collider-Tests should be kept in the test packages. There is really actually only the collider tested (if we ignore the LCP part)
Also, I think, simple JointTests should go into the test packages.
Also the space-tests should stay in test.
I think, in samples should go testcases, were the interaction of different testcases is shown. e.g. several joints connected by each other, a car example, Isvans demo...

[hdietrich]

Does anyone know if there is a possibility to get a shell access to the CVS repository an Sourceforge. If there is no way we will loose the current history for the code when doing the repackaging.

[arne]

mmh that would be really bad

isn't there Subversion available now at sourceforge?
so if we move all that, we could also migrate to subversion - I believe subversion supports the moving of files and such...mmh it would be even better if a move to subversion would keep the old history...anybody some informations on that?

[hdietrich]

The developer CVS at Sourceforge is currently down and will be up only until tommorow again. Currently we can't do anything.

Subversion is nice, but it is not necessary - at the moment. I do not have any experience with moving content from CVS to Subversion either.

[swpalmer]

I know there is a script "cvs2svn" that is supposed to move stuff over to a Subversion repository and keep the history as best it can.

Games published by our own members! Check 'em out!

[arne]

maybe this clears it a bit up (just found it):

http://sourceforge.net/docman/display_doc.php?docid=29894&group_id=1

you should take a look at Chapters 15 to 17.

[hdietrich]

Thanks for that hint. So we should really think about moving the project to Subversion. The migration should be quite easy - as long as the CVS server is available again (see https://sourceforge.net/docs/E09#import)

I do not know if we need t_larkworthy for doing this, but I can access the forms for setting up subversion and migrating CVS tarballs to th Subversion project. So I think I can do this as well

[hdietrich]

Sourceforge CVS is up again. I just tried to setup a Subversion repository for JOODE, but it looks like I do not have permissions to do this. So we need t_larkworthy for setting up Suversion for JOODE.

[t_larkworthy]

Hello everyone. I will move the project over to Subversion next week. My last exam is on Wed but I have visitors for the weekend so I will do it on Tue-Wed next week.  Then I can get back to JOODING yay!

[hdietrich]

OK, great. I am heavily waiting on this, so we can get something on again.

Could you please assign the right to create tasks to me on Sourceforge, so we can track the todos in sourceforge?

[hdietrich]

I just added a Todo list to the webpage. This is no tracker, but it should give a overview of the status of JOODE.

[arne]

Ok - I fixed that JointSlider stuff, the testcase now works, there wasn't a bug in the Joint, but in the testcase (sign error)
mmh ... sourceforge seems to down again...or do we already have subversion?

[t_larkworthy]

OK hdietrich and arne. I have put you on task trackers. Finished all my exams now. Woo! can JOODE again soon

[hdietrich]

Great, I hope your exams were successful 

As soon as I find some time I will move the tasks from the homepage to the Sourceforge tasks and put a link to the page on Sourceforge.

[hdietrich]

Ok - I fixed that JointSlider stuff, the testcase now works, there wasn't a bug in the Joint, but in the testcase (sign error)
mmh ... sourceforge seems to down again...or do we already have subversion?

I have a very simple test for the JointSlider involving a Box and nothing else. This is nearly the same as SingleBodySliderTest, but it fails. Am I doing something wrong?

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38

package net.java.dev.joode.test.joint; import javax.vecmath.Vector3f; import net.java.dev.joode.body.Body; import net.java.dev.joode.geom.Box; import net.java.dev.joode.joint.JointSlider; import net.java.dev.joode.test.SimpleWorld; public class SliderTest extends SimpleWorld {    public SliderTest() {       super(true);       Box box1 = new Box(this.space, 2, 2, 2);       Body body1 = new Body(this.world);       body1.pos.setY(4);       body1.pos.setX(-4);       body1.mass.setBox(1, box1.getSide().getX(), box1.getSide().getY(), box1.getSide().getZ());       box1.setBody(body1);       this.gfxManager.addBinding(box1, this.view.getScene());         JointSlider slider = new JointSlider(this.world);         slider.attach(body1, null);         slider.setAxis(1, -1, 0);               view.getView().getTransform().lookAt(new Vector3f(0, 0, 10),             new Vector3f(0, 0, 0), new Vector3f(0, 1, 0));    }    public static void main(String[] args) throws InterruptedException {       SliderTest test = new SliderTest();       while(test.fps.runs()) {          test.step();       }    } }

Slowly I hazard a guess that there is something wrong with the moment of inertia created for a box...

[hdietrich]

t_larkworthy, could you clean up the feature requests on the Sourceforge page. I think that except of the trimesh request the requests are not appropriate anymore.

[arne]

I have a very simple test for the JointSlider involving a Box and nothing else. This is nearly the same as SingleBodySliderTest, but it fails. Am I doing something wrong?

Slowly I hazard a guess that there is something wrong with the moment of inertia created for a box...

the testcase looks ok

it should slide down on the slider, right? What is happening?

[hdietrich]

The box is "jumping" out of sight within two or three iteration steps.

[hdietrich]

As soon as I find some time I will move the tasks from the homepage to the Sourceforge tasks and put a link to the page on Sourceforge.

The tasks are now moved from the webpage to Sourceforge.

[t_larkworthy]

OK, cleaned up feature requests. Subversion migration has failed, and I have run out of time tonight to try and get it working. Will have to wait till the weekend I am afraid, as I am going on a team building exercise for 3 days :-)
Speak to you all soon.

Tom

[hdietrich]

Could you please make an announcement before you migrate to Subversion. I think it will take some time until the code is moved to Subversion. I do not want to have code changes I have to merge afterwards.

Another thing I'd like to know is what is your idea of how JOODE will go on. You are the project leader and administrator, but I see no directions from your side how JOODE will go on. Since I have joinde JOODE only arne and me are really working on the project. I am afraid JOODE will get stuck, as long as no one will have the ambition and vision in getting JOODE on. We need directions in this project.

[t_larkworthy]

yeah fair comments. I am just trying to finish off a masters at the moment before starting my PhD in Sept. I will be using JOODE for the PhD. Since Chrismas I have been really busy doing other stuff. So all I can say is bear with me for the time being. Anyways, exams are over. Most of the labour intensive elements of my course are over, I will be doing an image proccessing Summer project requireing a certain amount of programming effort but I plan to split my time between JOODE and that. I am also about to quit my part time job to give me a bit more time to play with.
I said when I started this project I could commit 5 hours a week to it. I put in alot more than that initially but since Jan I have not done anything. I will be getting back to that minimum figure imminently. I am going to Berlin next weekend though  ... so I am about to do a few hours now and maybe not a full week next week but should be back in full swing the week after.

I did say I was planning to do the Subversion switch on Tue, but as it happened it did not work. Sourceforge have not got their migration from sourceforge repository feature working yet so I will wait for that.

I need to see how everything is working at the moment before I can really say what direction things should go. But my current gut feeling is that we have plenty of features, enough for a version 1 release. So what needs doing is:
Make sure all the users methods have javadoc's.
Make sure there is methods for everything that is expected to be interacted with, (so no direct interaction with the force accumulator, for instance).
Intergrate the properties system with the code flow. i.e. which step method that should be used should be chosen via the properties file etc.
Write a logging system. I don't like extra dependancies like log4J. I am thinking something very simple. Maybe 3 levels, which all require the C style IO. (to avoid string concatinations)

Bigger things that need a bit more discussion are general architecture improvements. I was mentioning this at chrismas. I think it would be good if we could have an interceptor pattern for step events on Bodies and contruction of bodies and geometries etc. This will allow extra simulation behaviours to be snapped in easily. We could even refactor some of our existing ones out like gravity.

Anohter thing we should be thinking about is profiling. I am open to suggestions on a stratergy for this. I don't have much experience of proper profiling. AOP seems like a good general purpose maintainable solution.

I am gonna catch up on the code base now...

[hdietrich]

I need to see how everything is working at the moment before I can really say what direction things should go. But my current gut feeling is that we have plenty of features, enough for a version 1 release.

That's right. But there is still a lot of work for a release. I already mentioned some time ago that I want to do a release, but there are still too many open things that should be finalized before we can have a release. I tried to add some to the tasks already. A roadmap would be fine, so if someone is willing to do something he can find subjects to do in a list.

Make sure all the users methods have javadoc's.
Make sure there is methods for everything that is expected to be interacted with, (so no direct interaction with the force accumulator, for instance).
Intergrate the properties system with the code flow. i.e. which step method that should be used should be chosen via the properties file etc.

All that is not that important for a release. The only really relevant thing for a first release (let's call it 0.5 before doing a 1.0 release) is that the code is stable und working. The API should not change dramatically anymore and of course everything must be working. And that's where I see the problems for a release right now. The API is not stable and I still have problems getting everything running. As soon as I start implementing more complex applications the physic system is exploding.

Write a logging system. I don't like extra dependancies like log4J. I am thinking something very simple. Maybe 3 levels, which all require the C style IO. (to avoid string concatinations)

Why not use the JAVA logging API? I would really discourage from an own logging API.

Bigger things that need a bit more discussion are general architecture improvements. I was mentioning this at chrismas. I think it would be good if we could have an interceptor pattern for step events on Bodies and contruction of bodies and geometries etc. This will allow extra simulation behaviours to be snapped in easily. We could even refactor some of our existing ones out like gravity.

Yeah, I've got lots of ideas as well. But let's get the current code clean and running and it should be no problem to make improvements in the future.

[Amos Wenger]

I need to see how everything is working at the moment before I can really say what direction things should go. But my current gut feeling is that we have plenty of features, enough for a version 1 release.

That's right. But there is still a lot of work for a release. I already mentioned some time ago that I want to do a release, but there are still too many open things that should be finalized before we can have a release. I tried to add some to the tasks already. A roadmap would be fine, so if someone is willing to do something he can find subjects to do in a list.

Sorry if you find this junk but I agree with t_larkworthy. The Wine project (http://www.winehq.org) do has a lot of feature and yet they began their X.Y numbering with 0.9. They're actually at 0.9.14 (which I'm actually upgrading to). A 1.0 release is not a small thing, see ODE which is still at 0.5 !

[hdietrich]

I need to see how everything is working at the moment before I can really say what direction things should go. But my current gut feeling is that we have plenty of features, enough for a version 1 release.

That's right. But there is still a lot of work for a release. I already mentioned some time ago that I want to do a release, but there are still too many open things that should be finalized before we can have a release. I tried to add some to the tasks already. A roadmap would be fine, so if someone is willing to do something he can find subjects to do in a list.

Sorry if you find this junk but I agree with t_larkworthy. The Wine project (http://www.winehq.org) do has a lot of feature and yet they began their X.Y numbering with 0.9. They're actually at 0.9.14 (which I'm actually upgrading to). A 1.0 release is not a small thing, see ODE which is still at 0.5 !

If you read the whole mail you will see that I suggest to start with 0.5 before heading towards a 1.0 release.