Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/Azure/autorest.java below:

Azure/autorest.java: Extension for AutoRest (https://github.com/Azure/autorest) that generates Java code

This is the next gen (v4) of AutoRest Java generator. It's built on AutoRest v3, written in Java, and supports OpenAPI3. It generates clients that work with com.azure:azure-core.

You need to have the following installed on your machine:

• Node.JS v12+
• Java 11+
• Maven 3

You need to have autorest installed through NPM:

To use the latest released preview(https://github.com/Azure/autorest.java/releases), run

autorest --java
    --use:@autorest/java@4.x.x
    --input-file:path/to/specs.json
    --output-folder:where/to/generate/java/files
    --namespace:specified.java.package

The first time running it will take a little longer to download and install all the components.

To build from source code, clone this repo and checkout to main branch. Make sure all prerequisites are met, and run

This will build a file javagen-jar-with-dependencies.jar under javagen module, a fluentgen-jar-with-dependencies.jar under fluentgen module.

And then run AutoRest

autorest --java
    --use:where/this/repo/is/cloned/autorest.java
    --input-file:path/to/specs.json
    --output-folder:where/to/generate/java/files
    --namespace:specified.java.package

Java files will be generated under where/to/generate/java/files/src/main/java/specified/java/package.

To debug, add --java.debugger to the argument list. The JVM will suspend at the beginning of the execution. Then attach a remote debugger in your IDE to localhost:5005. Make sure you detach the debugger before killing the AutoRest process. Otherwise it will fail to shutdown the JVM and leave it orphaned. (which can be killed in the Task Manager)

• use-default-http-status-code-to-exception-type-mapping: true, use subclass of HttpResponseException defined in azure-core, when service returns unexpected status code.

• generic-response-type: true, use ResponseBase<>, instead a subclass of ResponseBase<>, for response with HTTP headers. Performance and reflective access improvement.

• no-custom-headers: true, generates overloads of interface methods that exclude typed headers. Performance improvement by removing the need to convert header strings to Java types.

• required-fields-as-ctor-args, create a constructor taking required properties, for model classes. The correctness of this constructor highly depends on the correctness of Swagger.

• output-model-immutable: true, make model classes immutable, if model is used only in response.

• enable-sync-stack: true, let sync method invoke sync RestProxy method.

• enable-page-size: true, let maxpagesize query parameter be supplied via byPage API in PagedFlux or PagedIterable.

• use-key-credential: true, use KeyCredential in builder for API key.

• generate-client-as-impl: true, generate Client in implementation package, for customization.

• models-subpackage: implementation.models, generate model classes in implementation package.

• custom-types-subpackage: models, generate selected model classes in models package.

Settings can be provided on the command line through --name:value or in a README file through name: value. The list of settings for AutoRest in general can be found at https://github.com/Azure/autorest/blob/main/docs/user/command-line-interface.md. The list of settings for AutoRest.Java specifically are listed below:

data-plane option enables the generator to generate code for minimal data-plane clients.

data-plane option will change the default value for some vanilla options. For example, generate-client-interfaces, generate-client-as-impl, generate-sync-async-clients, generate-builder-per-client, enable-sync-stack, required-fields-as-ctor-args option is by default true. polling is by default enabled as default settings globally (polling={}).

sdk-integration option can be used for integrating to azure-sdk-for-java.

generate-samples option can be used for generating samples for client. generate-tests option can be used for generating tests for client.

See documentation for frequently used options, and their effect on generated clients.

fluent option enables the generator extension for Azure Management Libraries for Java.

Following settings only works when fluent option is specified.

fluent option will change the default value for some vanilla options. For example, generate-client-interfaces, required-parameter-client-methods option is by default true.

The code formatter would require Java 11+ runtime.

Polling configurations can be set through --polling setting globally or for each operation. The format is a key value map specified below:

polling:
  {operationId}:
    strategy: {strategy}
    sync-strategy: {sync-strategy}
    intermediate-type: {intermediate-type}
    final-type: {final-type}
    poll-interval: {poll-interval}

With the fields specified below:

To use default settings globally, use --polling={}.

By default, Swagger definitions will contain an exception type to be thrown when any error HTTP status code is seen. Swaggers may also define the error HTTP status code to exception type mapping, but isn't always the case. Or, it may be needed to change the default exception type to a custom type. In these cases it is possible to configure the error HTTP status code to exception type handling by using the configurations --default-http-exception-type, --use-default-http-status-code-to-exception-type-mapping, and --http-status-code-to-exception-type-mapping.

NOTE: Using the configurations on an already shipped library will likely result in runtime breaking changes as most libraries are already using a sub-class type of HttpResponseException and changing sub-types is a breaking change.

The default exception type is used for all error HTTP response status codes that do not have an explicit exception type configured. Generally, there is no error HTTP response status code to exception type mapping, so this will become your general exception type. The following is an example of configuring com.azure.core.exception.HttpResponseException as the default exception type:

autorest --default-http-exception-type=com.azure.core.exception.HttpResponseException

or in the Swagger README configuration:

default-http-exception-type: com.azure.core.exception.HttpResponseException

If this configuration isn't used the default exception type will be based on the Swagger definition.

The default error HTTP status code to exception type map is the following:

By default, this mapping isn't used, to use it pass the --use-default-http-status-code-to-exception-type-mapping to the generator or in the Swagger README configuration:

use-default-http-status-code-to-exception-type-mapping: true

If you need to have a custom mapping it is possible to do so by using --http-status-code-to-exception-type-mapping. This requires additional configuration in the Swagger README definition as it is a mapping of HTTP status code to exception. The following is an example:

http-status-code-to-exception-type-mapping:
  404: com.azure.core.exception.ResourceNotFoundException
  412: com.azure.core.exception.ResourceExistsException

The HTTP status code to exception type handling configurations can be used together to offer a nice baseline default with additional customizations as need. For example, if you wanted to configure the default exception type, use most of the default error HTTP status code to exception type, and customize one error HTTP status code exception type the following configurations can be used.

default-http-exception-type: com.azure.core.exception.HttpResponseException
use-default-http-status-code-to-exception-type-mapping: true
http-status-code-to-exception-type-mapping:
  404: com.azure.core.exception.ResourceExistsException

This results in the following error HTTP response to exception type mapping:

Notices how 404 changes from the default com.azure.core.exception.ResourceNotFoundException to com.azure.core.exception.ResourceExistsException.

You can generate the output as minimal data-plane clients with --data-plane flag. The models will not be generated and the methods in the clients will be generated as protocol methods.

The generated code has the following structure:

- pom.xml
- /src/main/java
  |
  - module-info.java
  - /com/azure/<group>/<service>
    |
    - <Service>Builder.java
    - <Service>Client.java
    - <Service>AsyncClient.java
    - /implementation
      |
      - <Service>ClientImpl.java

and requires latest azure-core as a dependency.

For guidance on using the post-code generation customization framework see its documentation.

This contains the actual generator extension, including mappers that maps a code model to a Java client model, and templates that writes the Java client models into .java files.

This contains the generator extension for Azure Management Libraries.

This contains the generated classes from the test swaggers in src/main. The code here should always be kept up-to-date with the output of the generator in javagen.

This also contains test code for these generated code under src/test. Running the tests will hit the test server running locally (see https://github.com/Azure/autorest.testserver for instructions) and verify the correctness of the generated code.

This repository uses a git submodule for the TypeSpec OSS core.

This section covers some basic everyday tasks for working with it. The steps below are are really just one possible workflow. There's more than one way to accomplish these tasks and if you prefer to do it differently, that's fine too!

Run the following command:

git config --global submodule.recurse true

This will effectively pass --recurse-submodules for you to git commands that accept it. It should eliminate some of the common pain points around submodules.

NOTE: git clone is exceptional, see below.

git clone does not recurse submodules automatically, even with submodule.recurse=true as configured above.

Fork the repo, then clone recursively as follows:

git clone --recurse-submodules https://github.com/(your_username)/autorest.java

In some situations, even with the above setting, you may still end up with the core/ folder being uninitialized and not having a good clone of microsoft/typespec, or with the core/ folder initialized, but checked out to the wrong commit for the current branch. To fix this, run the following command to update and initialize the submodule:

git submodule update --init

You can change the remotes of the submodule so that origin is your fork of microsoft/typespec rather than microsoft/typespec itself, and microsoft/typespec is upstream:

cd [repo_root]
cd core
git remote remove origin
git remote add origin https://github.com/(your_username)/typespec
git remote add upstream https://github.com/microsoft/typespec

Run "Build-TypeSpec.ps1" script to build @azure-tools/typespec-java as TypeSpec emitter.

The TypeSpec emitter can be installed via e.g.

npm install [repo_root]/typespec-extension/azure-tools-typespec-java-[version].tgz

Run "Build-AutoRest.ps1" script to build @autorest/java as Autorest extension.

The AutoRest extension can be used via e.g.

autorest --use="[repo_root]" --java [readme.md]

⚠️ the script would "checkout" unstaged code in "./core" submodule. Please stage/commit your code there.

Before building Maven project and packaging NPM package, the script does 3 things:

1. Apply a patch to code in "core", mainly for switching to azure-autorest-customization as customization lib. -- This is the only step that affect AutoRest extension.
2. Build the JAR for core/packages/http-client-java/generator/http-client-generator module (with the patch to code in step 1), and copy it to typespec-extension/generator/http-client-generator.
3. Copy the source from core/packages/http-client-java/emitter (with the patch to code in step 1) to typespec-extension.

If you do not plan to modify these patched files in your PR, you can use "assume-unchanged" to ignore the changes on these files:

git update-index --assume-unchanged packages/http-client-java/generator/http-client-generator-core/pom.xml packages/http-client-java/generator/http-client-generator-core/src/main/java/com/microsoft/typespec/http/client/generator/core/postprocessor/Postprocessor.java packages/http-client-java/generator/http-client-generator/src/main/resources/readme/pom.xml

"no-assume-unchanged" would unset the files marked by "assume-unchanged".

Alternatively, you can commit the patched files, and revert this commit before creating the pull request for review.

1. Make matching branches:

cd core
git checkout -b featurebranch

cd ..
git checkout -b featurebranch

1. Make your changes as needed to both repos.

2. Commit changes to both repos:

cd core
git commit -a -m "Core part of my change"

cd ..
git commit -a -m "Azure-specific part of my change"

1. Push

git push origin featurebranch

NOTE: If you configured submodule.recurse=true as shown above, this will automatically push the submodule typespec branch along with the autorest.java branch. If you prefer not to use that, then cd core and push that too.

1. Create 2 PRs from the two branches that were pushed to your microsoft/typespec and Azure/autorest.java forks. Start with the microsoft/typespec PR, then follow up with the Azure/autorest.java PR that depends on it.

2. Get approval for both PRs before merging either of them.

3. Merge the microsoft/typespec PR first.

4. Update the submodule to point to the actual commit you merged to microsoft/typespec main:

cd core
git fetch --all
git checkout upstream/main

cd ..
git commit -a -m "Update submodule"
git push origin featurebranch

1. Merge the autorest.java PR and you're done.

Note that you only need to do all of the above when your changes span both repos. If you are only changing one repo or the other, then just work in each individual repo as you would any other.

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

• Please don't edit this section unless you're re-configuring how the Java extension plugs in to AutoRest AutoRest needs the below config to pick this up as a plug-in - see https://github.com/Azure/autorest/blob/main/docs/developer/architecture/AutoRest-extension.md

use: $(this-folder)/javagen

use: $(this-folder)/fluentgen

help-content:
  java:
    activationScope: java
    categoryFriendlyName: Java Generator
    settings:
      - key: client-side-validations
        type: bool
        description: Generate validations for required parameters and required model properties. Default is false.
      - key: generate-client-as-impl
        type: bool
        description: Append "Impl" to the names of service clients and method groups and place them in the `implementation` sub-package. Default is false.
      - key: generate-client-interfaces
        type: bool
        description: Implies `--generate-client-as-impl` and generates interfaces for all the "Impl"s. Default is false.
      - key: generate-sync-async-clients
        type: bool
        description: Implies `--generate-client-as-impl` and generates sync and async convenience layer clients for all the "Impl"s. Default is false.
      - key: generate-builder-per-client
        type: bool
        description: Requires `--generate-sync-async-clients`, and generates one ClientBuilder for each Client. Default is false.
      - key: implementation-subpackage=STRING
        type: string
        description: The sub-package that the Service client and Method Group client implementation classes will be put into. Default is `implementation`.
      - key: models-subpackage=STRING
        type: string
        description: The sub-package that Enums, Exceptions, and Model types will be put into. Default is `models`.
      - key: sync-methods
        type: string
        description: \[all|essential|none] Specifies mode for generating sync wrappers. Supported value are <br>&nbsp;&nbsp;`essential` - generates only one sync returning body or header (default) <br>&nbsp;&nbsp;`all` - generates one sync method for each async method<br>&nbsp;&nbsp;`none` - does not generate any sync methods
      - key: required-parameter-client-methods
        type: bool
        description: Indicates whether client method overloads with only required parameters should be generated. Default is false.
      - key: custom-types
        type: string
        description: \[COMMA,SEPARATED,STRINGS] Specifies a list of files to put in the package specified in `--custom-types-subpackage`.
      - key: custom-types-subpackage
        type: string
        description: The sub-package that the custom types should be generated in. The types that custom types reference, or inherit from will also be automatically moved to this sub-package. **Recommended usage** You can set this value to `models` and set `--models-subpackage=implementation.models`to generate models to `implementation.models` by default and pick specific models to be public through `--custom-types=`.
      - key: client-type-prefix
        type: string
        description: The prefix that will be added to each generated client type.
      - key: client-flattened-annotation-target
        type: string
        description: \[TYPE,FIELD,NONE,DISABLED] Indicates the target of `@JsonFlatten` annotation for `x-ms-client-flatten`. Default is `TYPE`.
      - key: disable-client-builder
        type: bool
        description: Indicates whether to disable generating the `ClientBuilder` class. This is for SDK that already contains a hand-written `ClientBuilder` class. Default is false.
      - key: polling
        type: string
        description: Configures how to generate long running operations. See [Polling Configuration](https://github.com/Azure/autorest.java#polling-configuration) to see more details on how to use this flag.
      - key: service-name
        type: string
        description: Service name used in Client class and other documentations. If not provided, service name is deduced from `title` configure (from swagger or readme).
      - key: partial-update
        type: bool
        description: Indicates whether to support partial update for `Client`/`AsyncClient` classes and `ClientBuilder` class. Default is false.
      - key: enable-sync-stack
        type: bool
        description: Indicates that sync method invokes sync RestProxy method. By default, sync method invokes async RestProxy method.
      - key: required-fields-as-ctor-args
        type: bool
        description: Indicates that class models have constructor taking required properties.
      - key: output-model-immutable
        type: bool
        description: Indicates that output-only models be generated as immutable, and without public constructor. Default is false.
      - key: data-plane
        type: bool
        description:  Indicates whether to generate code for minimal clients. Default is false.

  javafluent:
    activationScope: fluent
    categoryFriendlyName: Java fluent Generator
    settings:
      - key: fluent
        type: string
        description: Enum. `LITE` for Fluent Lite; `PREMIUM` for Fluent Premium. Case insensitive. Default is `PREMIUM` if provided as other values.
      - key: fluent-subpackage
        type: string
        description: String. The sub-package that vanilla client and builder will be put into. Default is `fluent`.
      - key: pom-file
        type: string
        description: String. Name for Maven POM file. Default is `pom.xml`.
      - key: package-version
        type: string
        description: String. Version number for Maven artifact. Default is `1.0.0-beta.1`.
      - key: service-name
        type: string
        description: String. Service name used in Manager class and other documentations. If not provided, service name is deduced from `title` configure (from swagger or readme).
      - key: sdk-integration
        type: bool
        description: Boolean. Integrate to [azure-sdk-for-java](https://github.com/Azure/azure-sdk-for-java/). Default is `false`. Provide `output-folder` as absolute path for best performance.
      - key: generate-samples
        type: bool
        description: Boolean. Generate samples from `x-ms-examples` in swagger. Default is `false`.
      - key: add-inner
        type: string
        description: CSV. Treat as inner class (move to `fluent.models` namespace, append `Inner` to class name).
      - key: remove-inner
        type: string
        description: CSV. Exclude from inner classes.
      - key: rename-model
        type: string
        description: CSV. Rename classes. Each item is of pattern `from:to`.
      - key: remove-model
        type: string
        description: CSV. Remove classes.
      - key: preserve-model
        type: string
        description: CSV. Preserve classes from clean-up.
      - key: remove-operation-group
        type: string
        description: CSV. Remove operation groups.
      - key: name-for-ungrouped-operations
        type: string
        description: String. Name for ungrouped operation group. Default to `ResourceProviders` for Lite.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4