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).
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.
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.