The proposal is to change the semantics of uses to indicate that the remote library to be used is available as a local asset, using a local namespace.
Using uses does NOT automatically import the remote library's assets into the local file, but it allows the local file to import those assets by referring to them in its contents: e.g., a RAML type fragment file that uses a library of remote types can then import one of those types by referring to it, and that remote type will be included as if it were defined locally within the RAML type fragment file.
The namespaces defined in a uses statement in a file are only consumable within that file, i.e. they are only used to disambiguate the included libraries from each other within that file.
This proposal also expands the use of uses to allow its use in a root ("master") RAML file as well as in all RAML fragment files.
The uses keyword may ONLY be used at the root of a RAML file (either a root ["master"] RAML file or a RAML fragment file), and its value MUST be the location of a RAML library file.
This proposal is aimed to simplify the conceptual model of consuming libraries, and better support modularity of API definitions, e.g. by eliminating artificial dependency cycles (https://github.com/mulesoft/api-workbench/issues/29).
The proposal is to change the semantics of
uses
to indicate that the remote library to be used is available as a local asset, using a local namespace.Using
uses
does NOT automatically import the remote library's assets into the local file, but it allows the local file to import those assets by referring to them in its contents: e.g., a RAML type fragment file thatuses
a library of remote types can then import one of those types by referring to it, and that remote type will be included as if it were defined locally within the RAML type fragment file.The namespaces defined in a
uses
statement in a file are only consumable within that file, i.e. they are only used to disambiguate the included libraries from each other within that file.This proposal also expands the use of
uses
to allow its use in a root ("master") RAML file as well as in all RAML fragment files.The
uses
keyword may ONLY be used at the root of a RAML file (either a root ["master"] RAML file or a RAML fragment file), and its value MUST be the location of a RAML library file.This proposal is aimed to simplify the conceptual model of consuming libraries, and better support modularity of API definitions, e.g. by eliminating artificial dependency cycles (https://github.com/mulesoft/api-workbench/issues/29).