Hi Kohsuke,
Yes. That could work, and that can be implemented quickly (important!)
> But since you are in position to be able to generate code, I think
> generating the dumb toString() is not a bad idea either. It reduces a
> dependency, for one thing.
I've got a simple/dumb toString generation (using Jakarta commons) working.
1) How can I add more package imports to the beginning of the generated
class, so I don't need to refer to the fully qualified class names in the
methods ?
2) Is it common practice to pass additional config info to running the xjc
plugin, so it can, say, generate toString using different ToStringStyle, or
whether a toXml() should be generated or not, etc. ? If so, is System
properties to way to go, or there is a better way ?
I think using JAXB would be also not that hard. The only thing you need
> to be careful is that if the class doesn't have @XmlRootElement (you can
> tell that from !CClassInfo.isElement()), then you need to wrap it to
> JAXBElement before you marshal.
Interesting.
If it's not too much overhead to handle multiple small projects, I'd
> actually suggest you create a different source tree and etc. But that's
> up to you.
What would be some good names for these small projects ? Any suggestion ?
Can you create the tree roots so I can check stuff in, or do I have the
permission to do so ?
Hanson