-----Original Message----- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 5:52 PM To: OJB Users List Subject: RE: automatic generation of XML mapping files from Java codebase
> Personally I think xdoclet + jdo is as good as possible with the current > state of java (untyped collections). How do you propose to specify the > type a container object is supposed to contain without additional metadata? Untyped collections are a big issue. Currently, however, there are solutions for serializing amorphous collections (java's built in serialization and other mechanisms support such collections)- but the only general ones I can think of would involve doing something ugly (such as converting the collection to a blob or clob). > How do you propose to specify which classes should be persistent? One would specify which classes would need mappings, and the mapping tool would examine those classes and generate maps for them. Now, if one doesn't know what type of objects will be serialized ahead of time there would be no benifit to such an auto-mapper. > Maintaining this type of info outside the java file is ludicrous, therefore > it needs to be maintained in the java file. That's my point. At the same time one doesn't want to "mark-up" code (obviously it is very easy to get out of sync doing that) especially for a large application with 3rd party modules. > Do you have a better idea than javadoc tags? As I said before my idea is that the code itself is the source of its own mappings. The standalone mapping program would take "meta-maps" (for mapping to OJB, Hibernate, Castor, or whatever; also to define the "default" and "specific" behavior for how classes map to tables (one table per class...)). The first group of meta-maps would be needed (but general to all classes), and the second group of meta-maps would be optional (to override or fine tune default behavior). > One of my clients is using xdoclet + 2 jdo implementations and it works > fine, even though the xdoclet jdo templates are very new. As with any use > of xdoclet, running the xml generation as part of the build assures that it > is up to date. For some that might be fine, but I know my fellow developers here would not take kindly to more coding conventions.... Not to mention the fact that a large chunk of what we want to store comes from 3rd party software. > In the future we will probably see this kind of metadata stored directly in > class files rather than external xml files, but I think it will still be > generated from javadoc tags in the source. The way I see it is that most of the information is already "implied" in the classes. Of course, the class itself doesn't tell if each class gets its own table (or there are foreign keys to parent classes...), amorphous collections are trouble..., but default behaviors and meta-maps might get around these issues.
