Hi Morgan,
Sorry for the inconvenience...see inline... Morgan Stake wrote: > > When using Castor 0.9.3 the Source Generator produced names in the following > manner: > > Schema: > <xsd:element name="thing"> > <xsd:complexType> > <xsd:attribute name="customer_name" use="optional"> > <xsd:simpleType> > <xsd:restriction base="xsd:string"> > <xsd:whiteSpace value="collapse"/> > <xsd:minLength value="0"/> > <xsd:maxLength value="4"/> > </xsd:restriction> > </xsd:simpleType> > </xsd:attribute> > </xsd:complexType> > </xsd:element> > > Java declaration of customer_name Source Generator 0.9.3 > _customerName > That was a bug: '_' is a valid Java character and was being removed accidently. > Accessor/Mutator: > getCustomerName() > setCustomerName(String ...) > > Java declaration of customer_name Source Generator 0.9.3.9 > _customerName > > Accessor/Mutator: > getCustomer_Name() > setCustomer_Name(String ...) > > Adopting 0.9.3.9 breaks our existing code! > Is there an option to set? Not directly (see next paragraph). I understand some people may experience compatability issues, however Castor is not even at version 1.0. To maintain backward compatibility for all releases up to 1.0 would be a huge maintenance nightmare. There will be a way for you to work around this in version 0.9.4 however when the binding file is introduced. It will enable you to control the java name for a given element or attribute declaration. So perhaps you can wait until version 0.9.4 if you would like to keep your naming conventions. > Is this changing again in 0.9.4? Only if we find another bug. We really try to fix the API and not cause a lot of pain for people with changes. Our goal is to have all 1.0 features available by version 0.9.5. There will be no API changes for any Castor version between 0.9.6 and 1.0 (only bug fixes + documentation). But both Castor 0.9.4 and 0.9.5 are subject to changes if we feel they will make version 1.0 a better product. > > I like that the generation is more faithful to the schema and I plan on changing > my existing code to conform. However, if this keeps changing without being > configurable my team will push me to abandoning Castor in favor of JAXB > (http://java.sun.com/xml/jaxb/). > This would be undesirable for many reasons, but > at least we'd be keeping up with the JavaSoft line... > That is a choice for you and your team. I don't have the time or energy to argue those types of points. Thanks for your feedback and concerns. --Keith ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
