I downloaded XMLBeans 2.4.0, read the doc, and played around with the easypo samples without any problems.
I'm having a problem with my real-world use, however. I have a main XML schema with numerous xs:includes for all the types. In a couple of those included schemas, there are some xs:enumerations that share the same exact 'value'. This doesn't seem very useful to me, but it does appear to be valid XML. My company is not the owner of the schema, so we need to deal with it as-is. Here's an example of the 'duplicate' enumerations: <?xml version="1.0" encoding="ISO-8859-1"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns=" http://www.knowledgecc.com/coplink/29" targetNamespace=" http://www.knowledgecc.com/coplink/29" version="29"> <xs:simpleType name="PropTypes"> <xs:restriction base="xs:string"> ...snip... <xs:enumeration value="CASH REGISTER"/> <xs:enumeration value="CASING ROLLER"/> <xs:enumeration value="CASINGS, SHELL"/> <xs:enumeration value="CASSETTE DUPLICATOR"/> <xs:enumeration value="CASSETTE DUPLICATOR"/> <xs:enumeration value="CASTING MACHINE"/> <xs:enumeration value="CAT"/> ...snip... </xs:restriction> </xs:simpleType> </xs:schema> When I try to run scomp on the main schema, it finds all the included schemas and generates all the binary xsb without error, and all the java classes without error. However, after that it gets an error like this (during the compiling?): [checking com.knowledgecc.coplink.x29.PropertyType] C:\DOCUME~1\DFRAHM~1.COM\LOCALS~1\Temp\xbean1726.d\src\com\knowledgecc\coplink\x29\PropertyType.java:492: cannot resolve symbol symbol : variable CASSETTE_DUPLICATOR_2 location: interface com.knowledgecc.coplink.x29.PropTypes static final com.knowledgecc.coplink.x29.PropTypes.Enum CASSETTE_DUPLICATOR_2 = com.knowledgecc.coplink.x29.PropTypes.CASSETTE_DUPLICATOR_2; It does many of these, then continues with other 'checking' lines, then completes with the following: [total 9625ms] 100 errors BUILD FAILED I'm guessing by the appended '_n' that two of the different processes/operations are handling the duplicate xs:enumeration values differently. One process ignores all the duplicates, but then the java code is still aware of them and generates 'value', 'value_2', and so on. Anyway, I've hopefully shown that I've done a reasonable amount of troubleshooting. I have the full output log, ran using the -verbose -debug options, if anyone wants to see it.