Hi Kohsuke,
Thanks for the response - I'll add my thoughts inline. Note that I'm
'thinking aloud' here and I haven't fully thought through the details,
but am interested in having a conversation to flush out the good and
bad points so that we might be able to end up in a better place.
On 3/17/06, Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_sun.com> wrote:
> 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."
Firstly, I agree that this approach wouldn't solve all the problems,
but then again neither does the current approach.
Secondly, I think the current instructions that one can provide to xjc
via way of appInfo in the schema could still be used to do simple
generation instructions such as package/class/field names.
Thirdly, if the user was to rename a field (or perhaps even a whole
class) the generator could look for the @XmlElement declaration. Eg,
continuing from my previous example, suppose the generator finds this:
@Entity
@Table(name="foo_tbl")
@XmlRootElement
class Foo
{
@Column(name="bar_column")
@XmlElement(name="Bar")
String username;
}
It wants to generate a field called "bar" for the xml element "Bar".
But it can look at the existing class, and discover that there is a
differently named field with that XmlElement annotation already and so
that must be the field that should be used. Any additional changes
could then be made to that. I initially thought of an annotation such
as @RenamedFrom("bar") but given that we already have the information
required in the existing annotations I think this makes more sense.
Of course this doesn't support changing the type of an element, but I
don't see that there's anything that can be done automatically to
support that case.
> 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.
Yeah I've had that thought too, but as we all know cvs is fairly
limited once you start making more substantial changes. In my current
work I laid a tag when on the first generated code so I could do this
if I needed, but I've lost confidence in it working as I want to make
more changes than I think it will allow (including simplifying code by
removing the use of inner classes).
> 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!
Another approach to this would be to leave the JAXB generation the
same, and then have some sort of stand alone java code merger that
could merge/fold the newly generated JAXB code into some modified (but
previously generated) code. I haven't fully thought this through as
well, and I think the example above about renaming fields shows that
whatever did this would have to know a bit about JAXB as well.
> > 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!
haha - yes, and I think you have good reason to be! Although I'm more
than happy to get my hands dirty on this if it looks feasible.
cheers
dim