Move org.exolab.castor.builder to org.castor.codegen package

The filename of castorbuilder.properties as well as the keys of the properties defined there should also be renamed.

I am actually not convinced that this should be done at all. Basically we are forcing users to amend their (ideally) fully functional applications when upgrading to Castor 1.1. So far, we have always tried to provide backwards compatibility wherever possible. Why not in this case ?

It shouldn't be too hard to support two "package names" for properties, if we choose to rename the default properties to a new package. At a time when someone decides to amend something, they can use global search & replace to rename existing properties. But I believe we all agree that we should be backwards compatible.

I quite recently had a look at some 'external' dependencies, and somehow I am starting to think that such a move will have quite some impact on things like the Maven plug-in for Castor, the Eclipse plugin, etc. All these Castor-related tools somehow expose the XML code generator, but do not restrict themselves to using it as a simple dependency. E.g. the Maven plug-in sub-classes SourceGenerator, and makes use of a lot of other classes. Somehow I am getting less and less keen to change the package name(s) as suggested here and elsewhere.

Can you please share your thoughts with me, whether it is a good idea to risk that we break external tools ?

Obviously, for external tools, if we do this change we'll need ot maintain backwards compatibility.

How about leaving the classes in the old packages declared deprecated for one or two releases and apply fixes only to the classes in the new packages. This should give all external tools some time to move their code to use the new packages and with every patch that we apply to the new packages we improve the pressure to migrate.

Simpler than that, just have an empty class (marked deprecated) in the old location that is:

public class OldClassName extends NewClassName {
}

and we'll exactly preserve function at the old class location.

Somehow I feel that the effort of creating a lot fo empty classes is not worth it. I don't know how you guys feel about this, but somehow I am in favour of closing this.

I still think that we should cleanup Castor's cluttered package hierarchy and as it seams right now this is the only way to do that.

I am also in favor of still doing this. I'm almost caught up from my trip (how many weeks has it been?) and almost ready to pick up where I left off.