Martin, Martin S. Weber wrote: > Quoting "Werner Guttmann" <[EMAIL PROTECTED]>: >> (...) >> Okay, before having a go at this, let's get focused a bit. There's >> already a work-around for this, as documented here: >> >> http://castor.org/reference/html/xml.code.generator.html#d0e4989 > > Do I understand this correctly that using this option will enable me to > do the following: > <enumBinding name="..."> > <enum-def> > <enumMember> > <value>M</value> > <javaName>M</javaName> > </enumMember> > <enumMember> > <value>m</value> > <javaName>m</javaName> > </enum-def> > </enumBinding> > > and resolve the clash this way? or will this still upcase the 2nd javaName? Actually, you'll be able to change the name of the constant itself, but as far as I knon, the name will still be upcased.
I actually had a look at the sources yesterday, and came up with a patch that should solve your problem. Can you please raise a new Jira and I will attach a patch fro you to have a look at. Having said that, this patch introduces some backward-compatibility problem ... though minor in nature. >> In other words, we are aware of this problem (and have been so for a >> couple of years). Let me see whether this actually satisfies you >> already. > > Well, maybe I should explain the way we (want to) use castor: we are > targetting a changing schema, and the schema is the ultimate source for > what's right or wrong. Ultimately we want to generate all from the > schema: the ddl, the java code for (un)serialization, schema checking, > storing and reading to/from DB. Yup, even creating the DB for us. We > will soon be in a position where manpower will be low, so we're > naturally interested in a solution that will DTRT just given the schema. > Having to groom two files instead of one is like .. uh .. suboptimal. > Another option would be to generate the binding file from the schema > with a stylesheet application, although then we're slowly going into a > direction where we won't need Castor at all anylonger. If we have to > maintain binding files, one of the selling points of castor (at least in > our perception) is lost. > > Nonetheless I'll try this. > >> And I am aware that this might still cause issues with code >> generation for Java 5.0 and higher, but here I am not 100% sure. Can you >> please try this, and see where it takes you. And please do come back and >> let us know about your findings. > > Given my disability (I'm confident on my side of things) to get castor > built, I'll try that. Thank you very much for the hint! > > >> >> I thin that your fix might actually be a valid one, but with Java 1.4 >> and no real enums available, there was no option available. >> >> Would you mind if I addressed the other shots later on ? Let's first >> address your problem (and solve it), and then we'll take it from there, >> right ? > > No prob, you're the knowledgable guy about castor, not me. I'll (try to) > play by your rules. Monday is testing time. > >>> (...) >>> shot 4: You generate code that doesn't compile when ignoring the case. >>> (Look at the source code generators output for the example I cited -- >>> you're getting a clash for dual 'M's.) >> Yes, we know. That's why we provide you with a binding file to manually >> override the naming conventions as used by the XML code generator where >> things do not work automagically. And that's on intention: we do NOT >> want to be a product that knows how to avoid all possible naming >> collisions. > > Yeah but why? It would be great if it avoided all possible naming > collisions by default, even on the cost of 'non-java' or 'ugly' names. > Human intervention is error-prone. Cars usually crash because they have > a human driver... > > >>> >>> I understand that the java naming conventions are different, and that >>> you like to generate code that follows the java culture. But the XML >>> culture is different. E.g. Look at those two elements: <starts-with> and >>> <starts-With>. Yes it's braindead, but they are two different elements. >>> Generating method names incorporating the fragment startsWith for *both* >>> is just wrong with regard to the XML culture (shot 5?). As you see this >>> applies to applying java naming conventions _in general_ to xml stuff. >>> >>> Yes the output is alien and ugly and ... Go complain to the W3C. It's >>> them who are braindead. If you want to make conformant XML processors, >>> you have to be braindead, too. There's just no choice. >> See my answer to shot 4. To repeat it, the answer is NO. We simply don't >> want to replicate (and thus multiply) their brain-deadness into the Java >> world. > > IMO the java world is not free of brain-deadness either so it's pain or > suffering :) But that's MO, and not related to our process here. > > Thanks for the reply. > > Regards, > > -Martin > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
