Code cleaning of Xith3D core complete!!!

Engines, Libraries and Tools Xith3D Forums
#1

Woohoo!!! I worked the whole day and the whole night and finally code cleaning of the core is finished…

I eliminated every single warning (except for one in texture cache. I didn’t get this generics working for it. Maybe someone could look for it?)
I fixed indentation.
I transscripted to Java 1.5 (Generics)

It should be absolutely compatible with the previous version)

Hey, croft, old buddy… relax. It is as (in)compatible to the Java3D API as it was before :wink:

This topic was on the todo list for so long. And finally it is done :slight_smile:

Qudus

#2

Great job, Congratulations.

http://www.xith.org/pages/credits.html

#3

[quote="<MagicSpark.org [ BlueSky ]>,post:2,topic:27912"]
Great job, Congratulations.

http://www.xith.org/pages/credits.html
[/quote]
Hey, thanks. Cool.

There are two more things included in this code cleaning. I have marked variabled private that are actually private and removed not needed ones.

#4

Hey, thanks. Cool.
[/quote]
Well, I remembered that I had to wait until I made the website again to have my name on it so I thought it would be nice to put your name before you do so ^^

Did you commit it ?

#5

[quote="<MagicSpark.org [ BlueSky ]>,post:4,topic:27912"]

Did you commit it ?
[/quote]
I just forgot to mention it in the first posting. It is part of the whole code cleaning process I made. So, yes it’s committed.

#6

Great effort!

#7

Now codecleaning on Xith-tk is complete, too. There hasn’t remained any single warning.

Complete? No! A small Gallican village…

well, all joking aside… Croft, could you please eliminate the warnings from your code, too? Thanks.

Marvin

#8

I eliminated remaining warnings. Croft, feel free to add my @author name to all the classes I modified (althought it’s not really me, but Eclipse 3.2).

#9

[quote="<MagicSpark.org [ BlueSky ]>,post:8,topic:27912"]
I eliminated remaining warnings. Croft, feel free to add my @author name to all the classes I modified (althought it’s not really me, but Eclipse 3.2).
[/quote]
Thanks.

#10

[quote="<MagicSpark.org [ BlueSky ]>,post:8,topic:27912"]
I eliminated remaining warnings. Croft, feel free to add my @author name to all the classes I modified (althought it’s not really me, but Eclipse 3.2).
[/quote]
Quoting from my tutorial:

"Programming in Parallel

There are many inherent challenges when multiple developers are modifying source code in the same repository. Frequently, changes made by one developer made lead to countless hours of debugging for others. A version control system cannot by itself remove this problem entirely. A combination of development practices, documentation, and consideration are required as well.

Code Ownership

When multiple developers are working on source code in the same repository, the simplest and safest method of preventing difficulties is the practice known as “code ownership”. When developers are practicing code ownership, each Java class source code file is assigned to a “code owner”, usually grouped by project or Java package. When a developer realizes that a modification or addition needs to be made to the source code, he contacts the appropriate code owner and negotiates who will make this change.

When code ownership is being practiced, developers resist the desire to make a quick bug-fix to other developers’ source code without informing them. This politely educates the code owner who created the bug or knows who did, obviates a subsequent debugging session by the code owner to fix the real bug created when the other developer “fixed” the first supposed bug, and can lead to source code which has a more logical and consistent design.

All developers who modify source code, for any reason whatsoever, should place their javadoc “@author” tag in the file and update the version date. This both alerts the other developers that changes in behavior may be due to modifications by other developers, provides credit where credit is due, and allows the code owner to track down those with experience and knowledge with certain code sections that may need debugging or enhancement. The latter is especially important with legacy source code and projects with high developer turnover. "
http://www.croftsoft.com/library/tutorials/version/

I am certain you must have already read this:
http://www.java-gaming.org/forums/index.php?topic=14351.msg114308#msg114308

Plus I was right in the middle of the upgrade to JAXB 2 which is requiring multiple changes all over the place. I am fairly certain this will create multiple CVS checkin conflicts. One of the reasons I practice code ownership is specifically to avoid this as it often requires hours to resolve when it occurs. See page 547 of my book.

I think I will be more comfortable with my Xith code back at the Whoola CVS repository for two reasons:

  1. It ensures code ownership during active development.
  2. It facilitates funding development of my Open Source contributions via ad banners.

On this second point, please add a hyperlink from the Xith website to my website so that people know where they can download the code and read the documentation. I will provide the URL’s in a few days.

#11

[quote=""]
It’s interesting, but not really applicable in real open-source projects IMHO. Eh think one time you’re away for one month : what can we do ? nothing ! becaue one month isn’t really that long and we can still consider you are still the owner of your source code and yet if there’s a bug which is clearly straight-forward to fix we could do it in 2 secs then we couldn’t, just because of “code ownership”.

What you say make sense to fight against accidental regressions done by well-intentioned yet doesnt-know-this-class-in.-detail developer. But heh you can’t be excused of commenting your code just because your its owner. Anyone willing to improve your code should be able to do so.

And one more thing… take a look at : http://www.xith.org/pages/license.html
Nowhere can I see that some code is owned by someone in particular, let alone to prohibit modifications to your code. Release a separate package with an explicit notice : “This is public code. You are not welcome to modify it. I want to be ranted at if something goes wrong”.

#12

In the case of xith3d conflicts while check-in/check-out are very rare and can be disregarded. For example you and me, we are 10 hour devided. We can certainly find a point in time, where a conflict will be nearly impossible. If there were far more developers actively contributing, we had to rethink it. But at the moment there’re only you, Amos and me (AFAIK). So the problems won’t be too heavy.

About the @author and file date thing: The CVS saves this information. So you’will always be able to know, hwo modified which sourcode at which time. No need to save to date in the source code and mess with the risk to forget to update it.

Which code are you talking about? Isn’t it xith code, so xith.org or xith3d.dev.java.net is the adress where to download it? Did I get you wrong?

#13

I agree with Qudus here.

Croft, if my changes don’t please you, just revert them to the precedent version, then switch to JAXB 2 as you want and remove yourself the warnings. I have nothing against it, just it’s heavier for you cause you have to do refactoring yourself, which isn’t your job.

#14

Well I regularly spend some time fixing CVS conflicts… But that’s not that long.