Hi, KARR, DAVID (ATTCINW) wrote: > The current documentation seems to be ambiguous in specifying how you > enable the "automatic" conflict resolution strategy. I've seen some > sections that say you set the > "org.exolab.castor.builder.automaticConflictResolution" property in > castorBuilder.properties to "true", and some to either "xpath" or > "type". The following is an excerpt of the castorbuilder.properties in SVN trunk:
<quote> # Specifies whether automatic class name conflict resolution # should be used or not to resolve name conflicts during code # generation. # TODO: document in reference guide # # Possible values: # - false (default) # - true # # <pre> # org.exolab.castor.builder.automaticConflictResolution # </pre> # org.exolab.castor.builder.automaticConflictResolution=false </quote> Once you have enabled automatic conflict resolution, you face an option to select the desired mode for conflict resolution, using SourceGenerator#setClassNameConflictResolver(String) Possible values are 'xpath' and 'type'. In case you select 'type' mode, there's another property to have a look at: <quote> # With automatic name conflict resolution enabled in type mode, this # property specifies the 'string' used to be inserted between # the actual element name and the type name. # TODO: document in reference guide # # Possible values: # - Any text (default 'By') # # Sample: # <pre> # org.exolab.castor.builder.automaticConflictResolutionTypeSuffix=CustomBy # </pre> # # <pre> # org.exolab.castor.builder.automaticConflictResolutionTypeSuffix # </pre> org.exolab.castor.builder.automaticConflictResolutionTypeSuffix=By </quote> The relevant documentation section is to be found at section 2.4.2.2 in the reference guide. http://castor.org/reference/html/xml.code.generator.html#d0e5215 > It doesn't appear to matter, however. I've tried setting it to > all three of "true", "type", and "xpath", but I still see binding > conflicts in the log, and it didn't appear to do anything but simply > overwrite the previous version in each case. > > The current documentation appears to be in a state of flux. I found > quite a few "tbd"s, empty sections, and other issues. I'm well aware of > the fact that getting documentation done for a product like this is > probably harder than the software development. Not really; it is a matter of time, and quite frequently areas where documentation is missing is more than 5 years old. But as always, any help would be appreciated. > > --------------------------------------------------------------------- > 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
