Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (755)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  CVS management & toolkit  (Read 1110 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Devvie

Everything's possible, but not everything's fun...

« Posted 2006-05-23 17:23:56 »

There's (at least) one thing I want to know : what is the toolkit exactly intented to be ?

Here's some of the reasons for its existance:

1. to coordinate and provide resources for Xith3D tool development
2. to create a central repository for Xith3D tools so they are easily accessable
3. 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.
I thought a bit about it and wanted to say some more "what should be done" (noise, as kevglass said  Cool ).
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.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Pages: [1]
  ignore  |  Print  

DesertCoockie (36 views)
2018-05-13 18:23:11

nelsongames (81 views)
2018-04-24 18:15:36

nelsongames (73 views)
2018-04-24 18:14:32

ivj94 (755 views)
2018-03-24 14:47:39

ivj94 (85 views)
2018-03-24 14:46:31

ivj94 (626 views)
2018-03-24 14:43:53

Solater (101 views)
2018-03-17 05:04:08

nelsongames (182 views)
2018-03-05 17:56:34

Gornova (408 views)
2018-03-02 22:15:33

buddyBro (1068 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!