New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sbt plugin reads xsds in non-deterministic order across OSes causing problems where there are namespace conflicts #207

Closed
caoilte opened this Issue Apr 6, 2013 · 3 comments

Comments

Projects
None yet
4 participants
@caoilte

caoilte commented Apr 6, 2013

If XSDs are not given their own package each, Scalaxb resolves namespace conflicts by arbitrarily assigning unique type names to generated code. This caused a problem for us under the sbt plugin when different O/S ran the code, because we found that Linux assigned different unique names to MacOSX.

This turned out to be because the SBT plugin was reading files in a different order on Linux than it was on MacOSX and that therefore it was choosing unique names in a different order.

This should be fixed by making sure that the SBT plugin (and other ways of running scalaxb) read XSD files in the same order regardless of the operating system.

This might seem like an edge-case bug of little stature, but it is very painful to encounter as it is non-trivial to diagnose the underlying problem and to apply the configuration so excellently documented in http://scalaxb.org/multiple-schema-files.

@smessmer

This comment has been minimized.

Show comment
Hide comment
@smessmer

smessmer Apr 23, 2013

Same problem here using the same linux on different PCs.

A WSDL file I parse defines an enum type and scalaxb creates a sealed trait and case objects for it.
Another WSDL file in the same package defines another enum type, but one enum value name clashes with an enum value name of the first file. Say for example:

EnumA(ValA, ValB)
EnumB(ValB, ValC)

Scalaxb then numbers the created case objects:

sealed trait EnumA
case object ValA extends EnumA
case object ValB1 extends EnumA

sealed trait EnumB
case object ValB2 extends EnumB
case object ValC extends EnumB

On a different PC, I got

sealed trait EnumA
case object ValA extends EnumA
case object ValB2 extends EnumA

sealed trait EnumB
case object ValB1 extends EnumB
case object ValC extends EnumB

I'm not able to check the received values with

if(received==ValB1)

because the numbering is different on different platforms.

Same problem here using the same linux on different PCs.

A WSDL file I parse defines an enum type and scalaxb creates a sealed trait and case objects for it.
Another WSDL file in the same package defines another enum type, but one enum value name clashes with an enum value name of the first file. Say for example:

EnumA(ValA, ValB)
EnumB(ValB, ValC)

Scalaxb then numbers the created case objects:

sealed trait EnumA
case object ValA extends EnumA
case object ValB1 extends EnumA

sealed trait EnumB
case object ValB2 extends EnumB
case object ValC extends EnumB

On a different PC, I got

sealed trait EnumA
case object ValA extends EnumA
case object ValB2 extends EnumA

sealed trait EnumB
case object ValB1 extends EnumB
case object ValC extends EnumB

I'm not able to check the received values with

if(received==ValB1)

because the numbering is different on different platforms.

@martiell

This comment has been minimized.

Show comment
Hide comment
@martiell

martiell Apr 23, 2013

Collaborator

For what it's worth, the maven plugin simply applies Collections.sort to the list of files (see #110) before processing.

I'm not sure whether this is the right thing to do, particularly when there are sub-directories under src/main/xsd, but that's how it is right now.

Collaborator

martiell commented Apr 23, 2013

For what it's worth, the maven plugin simply applies Collections.sort to the list of files (see #110) before processing.

I'm not sure whether this is the right thing to do, particularly when there are sub-directories under src/main/xsd, but that's how it is right now.

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Apr 23, 2013

Owner

The default *.xsd and *.wsdl should be sorted, but if the user specifies the order in the build file, I won't mess with it.

Owner

eed3si9n commented Apr 23, 2013

The default *.xsd and *.wsdl should be sorted, but if the user specifies the order in the build file, I won't mess with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment