Here’s some of the reasons for its existance:
- to coordinate and provide resources for Xith3D tool development
- to create a central repository for Xith3D tools so they are easily accessable
- to allow developers to use org.odejava.* packages with the confidance that they will be kept up to date with Xith3D API changes, that they are community supported and will always be available. Such packages are also licensed-alike with Xith3D, so there won’t be any nasty surprises.
This doesn’t mean a package will always be maintained - but when Xith3D changes are made, corresponding changes will be made in the Toolkit (not least because both are on my Eclipse build path so I instantly see when a change to Xith3D breaks something in the TK.
[/quote]
I thought a bit about it and wanted to say some more “what should be done” (noise, as kevglass said 8) ).
I think having both org.xith3d and com.xith3d packages is a bit confusing for new users.
I think we can make use of CVS (/SVN ? can we switch) modules to separate core and loaders, terrain, UI, etc…
I can conceive changing imports from org.xith3d to all com.xith3d would annoy users more than anything else. Maybe it’s worth keeping it like it.
Contributions as I see them are done like this :
- User download Xith3D build
- He has 10hours of spare time and implement an MD5 loader (e.g.)
- He post on the forum an announce he made that
- A core developer handle this demand, review the classes and give the guy developer access for the corresponding module (may be new if feature is totally innovant)
- The user commit its work and maintain it as long as possible, after what another can take care of it, or it can be dropped if superseded, or just left unmaintained
Why not ? In this case, toolkit isn’t needed.