scene package misplaced

Engines, Libraries and Tools Xith3D Forums
#1

Which of these is not like the others?

org.xith3d.loaders.ase
org.xith3d.loaders.dae
org.xith3d.loaders.ext
org.xith3d.loaders.md2
org.xith3d.loaders.obj
org.xith3d.loaders.scene
org.xith3d.loaders.tds

Let’s move the classes in package scene to org.xith3d.loaders.

#2

Well, actually there are two, that are not like the others: scene and ext. My suggestion is (and was) to create a package org.xith3d.loaders.scene.impl which will contain subpackages ase, dae, md2, obj and tds and leave the scene content as is. additionally move ext to scene and rename it to convenience, comfort or conv or something like that.

#3

well as you like but it is compatibility break one more time…

#4

[quote="<MagicSpark.org [ BlueSky ]>,post:3,topic:27799"]
well as you like but it is compatibility break one more time…
[/quote]

  1. We should wait with this until Eclipse 3.2 is out. Then we will have no problems with such changes.
  2. For version 9.0 I suggest massive refactorings, which will break the compatiblity. But with Eclipse 3.2 this won’t be a problem at all.

Pre 1.0 there should be massive clean ups and package reorganization. And I will love to do/help. What about Will? He seems to be absent most of the time. I really need dev access to the core. This ever commition over the forum is inefiicient.

#5

And we shouldn’t do it step by step, but in a whole. So people will have to replay our refactorings only once and not multiple times only a bit.

I suggest to start a separate CVS branch to develop the cleanup. Something like an alpha branch. When changes have esteblished/stabilized in this branch, we can commit it to the main branch.

#6
  1. We should wait with this until Eclipse 3.2 is out. Then we will have no problems with such changes.
  2. For version 9.0 I suggest massive refactorings, which will break the compatiblity. But with Eclipse 3.2 this won’t be a problem at all.

Pre 1.0 there should be massive clean ups and package reorganization. And I will love to do/help. What about Will? He seems to be absent most of the time. I really need dev access to the core. This ever commition over the forum is inefiicient.
[/quote]
(9.0 you mean 1.0, right ?)
Well I suggest we release a version 1.0 very soon with improved backward compatibility (e.g. provide an OldTextureLoader which is a wrapper of “TextureLoader2” but with the API of the old TExtureloader) yet clean API (change we did so far), then start a 2.0 branch and do all you suggest.

But the 2.0 branch shouldn’t be committed to the 1.0 one : not all projects are work-in-progress, like your and mine.

#7

Well, I meant 0.9. But 1.0 and then 2.0 is ok for me. And surely we shouldnt commit the changes to 1.0. You idea is even bettrer then mine. But we should anyway have such an alpha branch. At least for the 2.0 project. So we can change things in the alpha branch that should be looked at by some people and without disturbing all the people who use the API in thier projects/games. When a change has been agreed, it gets committed to the main branch with a refactoring fix for Eclipse.

This is best, isn’t it?

#8

The more I think about it, the more I like the idea of having a stable 1.0 API the way we have it now (or a little bit earlier, like the TextureLoader thing) and a 2.0 branch with a new hierarchy. Great idea.

#9

That’s the way APIs evolve.

#10

Go slowly and incrementally. Continue to make updates but make one update at a time.

Also, stick to the Java3D API.

A new book is coming out:
Foundations of 3D Graphics Programming: Using JOGL and Java3D
http://www.amazon.com/gp/product/1846281857/

Xith does JOGL and Java3D. If we drop Java3D API compatibility, Xith will lose all the programmers trained on the Java3D API books.

If you want to move Xith away from the Java3D API, please fork the code and call it something else.

#11

I think, making API changes again and again, it is just annoing. If we made one big API change (and call it version 2.0) it is one change for the users to adept their programs and will give the users a better feeling of stability.

Yes, that’s true.

But I think we can make small differences to the Java3D API that everyone will recognize instantly. E.g. the Scene class in the loaders package. If we go returning not arrays but a Vector or something like that, it would be clear to everyone what is meant. And not pushing all the items in an array to return it is much more efficient.

And package reorganization is not disturbing at all, when it’s done from the beginning. Since 99.9% of the developers use a recent IDE (mostly Eclipse I assume) you will just type the class name and then press CTRL+Space and the appropriate import is set without the user noticing the difference. For the case, the API changes after it has bee once released, there are solutions for it I talked about previously.

So I agree, that we should stay close to the Java3D API, but we don’t have to be exactly the same. If we didn’t make things different when it makes sense and when it’s not too far away from the API we are referencing at, we didn’t need to write a new API.

#12

I disagree on this. If you make a lot of changes all at once, people just give up, especially if there are time-consuming problems.

I might agree here on a case-by-case basis but it is probably less time consuming for everyone if we have a default policy of sticking to the Java3D API the way it is and just handle the exceptions as they come.

#13

This is why if a 2.0 version comes out you will stick to the 1.0 one.