I’ll quote from the most official unofficial guide on JAXB on the net.
When schemas contain similar looking element/type names, they can
result in “Two declarations cause a collision in the ObjectFactory
class” errors. To be more precise, for each of all types and many
elements (exactly what elements get a factory and what doesn’t is bit
tricky to explain), XJC produces one method on the ObjectFactory class
in the same package. The ObjectFactory class is created for each
package that XJC generates some files into. The name of the method is
derived from XML element/type names, and the error is reported if two
elements/types try to generate the same method name.
That said, you have two options.
The first is to define an external binding XML like this
<jaxb:bindings xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
version="1.0">
<jaxb:bindings schemaLocation="Core.xsd">
<jaxb:bindings node="//xs:element[@name="BioSampleSet"]/xs:complexType">
<jaxb:factoryMethod name="TypeBioSampleSet"/>
</jaxb:bindings>
<jaxb:bindings node="//xs:element[@name="TargetBioSampleSet"]/xs:complexType">
<jaxb:factoryMethod name="TypeTargetBioSampleSet"/>
</jaxb:bindings>
</jaxb:bindings>
</jaxb:bindings>
In the generated ObjectFactory class this will create two methods called createTypeBioSampleSet and createTypeTargetBioSampleSet (JAXB will append the name you specify to the word create) that can be used to produce BioSampleSet and TargetBioSampleSet objects.
(It’s not necessary to define a binding for both types.)
I’m not exactly sure why JAXB refuses to generate classes from the given schema, but when I specified only one binding (for BioSampleSet for example) then the other type’s factory method was named like createTypeProjectProjectTypeSubmissionWhateverThisAndThatTargetTargetSampleBioCatDogWoofTypeIDoNotKnowWhatElse so I think JAXB choked on this long method identifier, because it somehow managed to create the same one for both types. I think this is some implementation detail in JAXB.
The other solution is to create a base type for a BioSampleSet and use that at both locations like this
<xs:element name="ProjectTypeSubmission">
...
<xs:element name="Target">
...
<xs:element name="BioSampleSet" type="typeBioSampleSet" minOccurs="0" maxOccurs="1"/>
...
</xs:element>
...
<xs:element name="TargetBioSampleSet" type="typeBioSampleSet"/>
...
<xs:element/>
...
<xs:complexType name="typeBioSampleSet">
<xs:sequence>
<xs:element name="ID" maxOccurs="unbounded" type="xs:token"></xs:element>
</xs:sequence>
</xs:complexType>
The best solution would be to drop every anonymous type declarations from your schema. If you can do that, do it, because this schema looks like a mess (to me at least).
remove -p package in the command
xjc -d src -XautoNameResolution TFMData_Service.xsd