You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 10, 2019. It is now read-only.
It is possible to reference parts of another specification like type definition.
As every specification has it's own name space (package), these types are not visible by default from referring controller, for example if specification B refers to the type Tpe defined in the specification A, the full names would be B.contoller and A.Tpe
The generated code must contain proper import statements.
The text was updated successfully, but these errors were encountered:
The problem is actually harder then just importing needed references. The reason for that is that it's not possible to ensure, that referenced model is actually generated as a part of another specification.
This would be true if referenced definition is defined as a part of another, but full specification.
This might be false if multiple different specification refer to the common standalone part with all type definitions.
In second case it would be appropriate to place all the generated types into the separate namespace and import them into all referencing specifications.
The issue probably has low priority.
For now, solving it by generating all referenced types explicitly in target namespace (multiple times, one time per namespace).
It is possible to reference parts of another specification like type definition.
As every specification has it's own name space (package), these types are not visible by default from referring controller, for example if specification
B
refers to the typeTpe
defined in the specificationA
, the full names would beB.contoller
andA.Tpe
The generated code must contain proper import statements.
The text was updated successfully, but these errors were encountered: