Dmitri Colebatch wrote:
> I also realise that I'm no longer talking about a generator, but
> instead am talking about an xml schema/java code one way synchonizer.
> The reason I think this is a better option is that it provides far
> greater flexibility.
In the early phase of JAXB 2.0 development, we discussed about those
approaches as well. I agree that it brings in many benefits, but OTOH I
was never convinced if one can define a smart enough "update" algorithm.
The case you mentioned was adding one field, so as you say, that's
simple enough. But some of the changes can be more substantial --- for
example, one of the things people want to do is to rename the
compiler-generated classes (placing it to a proper package can be
thought of as a renaming.) And I'm not aware of any good algorithm that
lets the compiler do "aha, this complex type is normally generated into
foo.bar.Zot but the user moved it to aaa.bbb.Ccc, so OK, I gotta put
update there."
If you have any good idea about how to do this nicely, I'm very interested.
So far, the one approach that I think could work is to use CVS and diff.
You generate code from schema, import that to the vendor branch, then
make changes locally. When your schema changes, you regenerate it,
import that to the vendor branch again, and then do a three-way merge.
> For our swing apps we use JFormDesigner which has a similar (although
> more simple) approach. I think that by offering this option many
> plugins could be replaced by altering the first cut of generated code.
Right. If it's possible, it brings the user experience to the whole new
level. For one thing, we won't need any JAXB customization anymore. Just
change the generated code!
> Anyway - some food for thought. What do others think of this approach
> (ignore for now the difficulty of implementing it).
Ah, but you see, that's all I'm concerned about!
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com