chore: regenerate addressvalidation client (googleapis#23936)

Generated in GitHub action: https://togithub.com/googleapis/googleapis/google-api-java-client-services/actions/workflows/codegen.yaml

Author: yoshi-code-bot

clients/google-api-services-addressvalidation/v1/2.0.0/README.md

@@ -22,7 +22,7 @@ Add the following lines to your `pom.xml` file:
     <dependency>
       <groupId>com.google.apis</groupId>
       <artifactId>google-api-services-addressvalidation</artifactId>
-      <version>v1-rev20241110-2.0.0</version>
+      <version>v1-rev20241120-2.0.0</version>
     </dependency>
   </dependencies>
 </project>
@@ -35,7 +35,7 @@ repositories {
   mavenCentral()
 }
 dependencies {
-  implementation 'com.google.apis:google-api-services-addressvalidation:v1-rev20241110-2.0.0'
+  implementation 'com.google.apis:google-api-services-addressvalidation:v1-rev20241120-2.0.0'
 }
 ```
 

clients/google-api-services-addressvalidation/v1/2.0.0/com/google/api/services/addressvalidation/v1/model/GoogleTypePostalAddress.java

@@ -17,14 +17,14 @@
 package com.google.api.services.addressvalidation.v1.model;
 
 /**
- * Represents a postal address, e.g. for postal delivery or payments addresses. Given a postal
- * address, a postal service can deliver items to a premise, P.O. Box or similar. It is not intended
- * to model geographical locations (roads, towns, mountains). In typical usage an address would be
- * created via user input or from importing existing data, depending on the type of process. Advice
- * on address input / editing: - Use an internationalization-ready address widget such as
+ * Represents a postal address. For example for postal delivery or payments addresses. Given a
+ * postal address, a postal service can deliver items to a premise, P.O. Box or similar. It is not
+ * intended to model geographical locations (roads, towns, mountains). In typical usage an address
+ * would be created by user input or from importing existing data, depending on the type of process.
+ * Advice on address input / editing: - Use an internationalization-ready address widget such as
  * https://github.com/google/libaddressinput) - Users should not be presented with UI elements for
  * input or editing of fields outside countries where that field is used. For more guidance on how
- * to use this schema, please see: https://support.google.com/business/answer/6397478
+ * to use this schema, see: https://support.google.com/business/answer/6397478
  *
  * <p> This is the Java data model class that specifies how to parse/serialize into the JSON that is
  * transmitted over HTTP when working with the Address Validation API. For a detailed explanation
@@ -40,18 +40,18 @@ public final class GoogleTypePostalAddress extends com.google.api.client.json.Ge
   /**
    * Unstructured address lines describing the lower levels of an address. Because values in
    * address_lines do not have type information and may sometimes contain multiple values in a
-   * single field (e.g. "Austin, TX"), it is important that the line order is clear. The order of
-   * address lines should be "envelope order" for the country/region of the address. In places where
-   * this can vary (e.g. Japan), address_language is used to make it explicit (e.g. "ja" for large-
-   * to-small ordering and "ja-Latn" or "en" for small-to-large). This way, the most specific line
-   * of an address can be selected based on the language. The minimum permitted structural
-   * representation of an address consists of a region_code with all remaining information placed in
-   * the address_lines. It would be possible to format such an address very approximately without
-   * geocoding, but no semantic reasoning could be made about any of the address components until it
-   * was at least partially resolved. Creating an address only containing a region_code and
-   * address_lines, and then geocoding is the recommended way to handle completely unstructured
-   * addresses (as opposed to guessing which parts of the address should be localities or
-   * administrative areas).
+   * single field (For example "Austin, TX"), it is important that the line order is clear. The
+   * order of address lines should be "envelope order" for the country/region of the address. In
+   * places where this can vary (For example Japan), address_language is used to make it explicit
+   * (For example "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). This
+   * way, the most specific line of an address can be selected based on the language. The minimum
+   * permitted structural representation of an address consists of a region_code with all remaining
+   * information placed in the address_lines. It would be possible to format such an address very
+   * approximately without geocoding, but no semantic reasoning could be made about any of the
+   * address components until it was at least partially resolved. Creating an address only
+   * containing a region_code and address_lines, and then geocoding is the recommended way to handle
+   * completely unstructured addresses (as opposed to guessing which parts of the address should be
+   * localities or administrative areas).
    * The value may be {@code null}.
    */
   @com.google.api.client.util.Key
@@ -60,9 +60,9 @@ public final class GoogleTypePostalAddress extends com.google.api.client.json.Ge
   /**
    * Optional. Highest administrative subdivision which is used for postal addresses of a country or
    * region. For example, this can be a state, a province, an oblast, or a prefecture. Specifically,
-   * for Spain this is the province and not the autonomous community (e.g. "Barcelona" and not
-   * "Catalonia"). Many countries don't use an administrative area in postal addresses. E.g. in
-   * Switzerland this should be left unpopulated.
+   * for Spain this is the province and not the autonomous community (For example "Barcelona" and
+   * not "Catalonia"). Many countries don't use an administrative area in postal addresses. For
+   * example in Switzerland this should be left unpopulated.
    * The value may be {@code null}.
    */
   @com.google.api.client.util.Key
@@ -100,7 +100,7 @@ public final class GoogleTypePostalAddress extends com.google.api.client.json.Ge
   /**
    * Optional. Postal code of the address. Not all countries use or require postal codes to be
    * present, but where they are used, they may trigger additional validation with other parts of
-   * the address (e.g. state/zip validation in the U.S.A.).
+   * the address (For example state/zip validation in the U.S.A.).
    * The value may be {@code null}.
    */
   @com.google.api.client.util.Key
@@ -134,9 +134,9 @@ public final class GoogleTypePostalAddress extends com.google.api.client.json.Ge
 
   /**
    * Optional. Additional, country-specific, sorting code. This is not used in most regions. Where
-   * it is used, the value is either a string like "CEDEX", optionally followed by a number (e.g.
-   * "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area
-   * indicator" (Malawi) or "post office indicator" (e.g. Côte d'Ivoire).
+   * it is used, the value is either a string like "CEDEX", optionally followed by a number (For
+   * example "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery
+   * area indicator" (Malawi) or "post office indicator" (For example Côte d'Ivoire).
    * The value may be {@code null}.
    */
   @com.google.api.client.util.Key
@@ -153,18 +153,18 @@ public final class GoogleTypePostalAddress extends com.google.api.client.json.Ge
   /**
    * Unstructured address lines describing the lower levels of an address. Because values in
    * address_lines do not have type information and may sometimes contain multiple values in a
-   * single field (e.g. "Austin, TX"), it is important that the line order is clear. The order of
-   * address lines should be "envelope order" for the country/region of the address. In places where
-   * this can vary (e.g. Japan), address_language is used to make it explicit (e.g. "ja" for large-
-   * to-small ordering and "ja-Latn" or "en" for small-to-large). This way, the most specific line
-   * of an address can be selected based on the language. The minimum permitted structural
-   * representation of an address consists of a region_code with all remaining information placed in
-   * the address_lines. It would be possible to format such an address very approximately without
-   * geocoding, but no semantic reasoning could be made about any of the address components until it
-   * was at least partially resolved. Creating an address only containing a region_code and
-   * address_lines, and then geocoding is the recommended way to handle completely unstructured
-   * addresses (as opposed to guessing which parts of the address should be localities or
-   * administrative areas).
+   * single field (For example "Austin, TX"), it is important that the line order is clear. The
+   * order of address lines should be "envelope order" for the country/region of the address. In
+   * places where this can vary (For example Japan), address_language is used to make it explicit
+   * (For example "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). This
+   * way, the most specific line of an address can be selected based on the language. The minimum
+   * permitted structural representation of an address consists of a region_code with all remaining
+   * information placed in the address_lines. It would be possible to format such an address very
+   * approximately without geocoding, but no semantic reasoning could be made about any of the
+   * address components until it was at least partially resolved. Creating an address only
+   * containing a region_code and address_lines, and then geocoding is the recommended way to handle
+   * completely unstructured addresses (as opposed to guessing which parts of the address should be
+   * localities or administrative areas).
    * @return value or {@code null} for none
    */
   public java.util.List<java.lang.String> getAddressLines() {
@@ -174,18 +174,18 @@ public java.util.List<java.lang.String> getAddressLines() {
   /**
    * Unstructured address lines describing the lower levels of an address. Because values in
    * address_lines do not have type information and may sometimes contain multiple values in a
-   * single field (e.g. "Austin, TX"), it is important that the line order is clear. The order of
-   * address lines should be "envelope order" for the country/region of the address. In places where
-   * this can vary (e.g. Japan), address_language is used to make it explicit (e.g. "ja" for large-
-   * to-small ordering and "ja-Latn" or "en" for small-to-large). This way, the most specific line
-   * of an address can be selected based on the language. The minimum permitted structural
-   * representation of an address consists of a region_code with all remaining information placed in
-   * the address_lines. It would be possible to format such an address very approximately without
-   * geocoding, but no semantic reasoning could be made about any of the address components until it
-   * was at least partially resolved. Creating an address only containing a region_code and
-   * address_lines, and then geocoding is the recommended way to handle completely unstructured
-   * addresses (as opposed to guessing which parts of the address should be localities or
-   * administrative areas).
+   * single field (For example "Austin, TX"), it is important that the line order is clear. The
+   * order of address lines should be "envelope order" for the country/region of the address. In
+   * places where this can vary (For example Japan), address_language is used to make it explicit
+   * (For example "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). This
+   * way, the most specific line of an address can be selected based on the language. The minimum
+   * permitted structural representation of an address consists of a region_code with all remaining
+   * information placed in the address_lines. It would be possible to format such an address very
+   * approximately without geocoding, but no semantic reasoning could be made about any of the
+   * address components until it was at least partially resolved. Creating an address only
+   * containing a region_code and address_lines, and then geocoding is the recommended way to handle
+   * completely unstructured addresses (as opposed to guessing which parts of the address should be
+   * localities or administrative areas).
    * @param addressLines addressLines or {@code null} for none
    */
   public GoogleTypePostalAddress setAddressLines(java.util.List<java.lang.String> addressLines) {
@@ -196,9 +196,9 @@ public GoogleTypePostalAddress setAddressLines(java.util.List<java.lang.String>
   /**
    * Optional. Highest administrative subdivision which is used for postal addresses of a country or
    * region. For example, this can be a state, a province, an oblast, or a prefecture. Specifically,
-   * for Spain this is the province and not the autonomous community (e.g. "Barcelona" and not
-   * "Catalonia"). Many countries don't use an administrative area in postal addresses. E.g. in
-   * Switzerland this should be left unpopulated.
+   * for Spain this is the province and not the autonomous community (For example "Barcelona" and
+   * not "Catalonia"). Many countries don't use an administrative area in postal addresses. For
+   * example in Switzerland this should be left unpopulated.
    * @return value or {@code null} for none
    */
   public java.lang.String getAdministrativeArea() {
@@ -208,9 +208,9 @@ public java.lang.String getAdministrativeArea() {
   /**
    * Optional. Highest administrative subdivision which is used for postal addresses of a country or
    * region. For example, this can be a state, a province, an oblast, or a prefecture. Specifically,
-   * for Spain this is the province and not the autonomous community (e.g. "Barcelona" and not
-   * "Catalonia"). Many countries don't use an administrative area in postal addresses. E.g. in
-   * Switzerland this should be left unpopulated.
+   * for Spain this is the province and not the autonomous community (For example "Barcelona" and
+   * not "Catalonia"). Many countries don't use an administrative area in postal addresses. For
+   * example in Switzerland this should be left unpopulated.
    * @param administrativeArea administrativeArea or {@code null} for none
    */
   public GoogleTypePostalAddress setAdministrativeArea(java.lang.String administrativeArea) {
@@ -288,7 +288,7 @@ public GoogleTypePostalAddress setOrganization(java.lang.String organization) {
   /**
    * Optional. Postal code of the address. Not all countries use or require postal codes to be
    * present, but where they are used, they may trigger additional validation with other parts of
-   * the address (e.g. state/zip validation in the U.S.A.).
+   * the address (For example state/zip validation in the U.S.A.).
    * @return value or {@code null} for none
    */
   public java.lang.String getPostalCode() {
@@ -298,7 +298,7 @@ public java.lang.String getPostalCode() {
   /**
    * Optional. Postal code of the address. Not all countries use or require postal codes to be
    * present, but where they are used, they may trigger additional validation with other parts of
-   * the address (e.g. state/zip validation in the U.S.A.).
+   * the address (For example state/zip validation in the U.S.A.).
    * @param postalCode postalCode or {@code null} for none
    */
   public GoogleTypePostalAddress setPostalCode(java.lang.String postalCode) {
@@ -369,9 +369,9 @@ public GoogleTypePostalAddress setRevision(java.lang.Integer revision) {
 
   /**
    * Optional. Additional, country-specific, sorting code. This is not used in most regions. Where
-   * it is used, the value is either a string like "CEDEX", optionally followed by a number (e.g.
-   * "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area
-   * indicator" (Malawi) or "post office indicator" (e.g. Côte d'Ivoire).
+   * it is used, the value is either a string like "CEDEX", optionally followed by a number (For
+   * example "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery
+   * area indicator" (Malawi) or "post office indicator" (For example Côte d'Ivoire).
    * @return value or {@code null} for none
    */
   public java.lang.String getSortingCode() {
@@ -380,9 +380,9 @@ public java.lang.String getSortingCode() {
 
   /**
    * Optional. Additional, country-specific, sorting code. This is not used in most regions. Where
-   * it is used, the value is either a string like "CEDEX", optionally followed by a number (e.g.
-   * "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area
-   * indicator" (Malawi) or "post office indicator" (e.g. Côte d'Ivoire).
+   * it is used, the value is either a string like "CEDEX", optionally followed by a number (For
+   * example "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery
+   * area indicator" (Malawi) or "post office indicator" (For example Côte d'Ivoire).
    * @param sortingCode sortingCode or {@code null} for none
    */
   public GoogleTypePostalAddress setSortingCode(java.lang.String sortingCode) {

clients/google-api-services-addressvalidation/v1/2.0.0/pom.xml

@@ -8,8 +8,8 @@
 
   <groupId>com.google.apis</groupId>
   <artifactId>google-api-services-addressvalidation</artifactId>
-  <version>v1-rev20241110-2.0.0</version>
-  <name>Address Validation API v1-rev20241110-2.0.0</name>
+  <version>v1-rev20241120-2.0.0</version>
+  <name>Address Validation API v1-rev20241120-2.0.0</name>
   <packaging>jar</packaging>
 
   <inceptionYear>2011</inceptionYear>

clients/google-api-services-addressvalidation/v1/README.md

@@ -22,7 +22,7 @@ Add the following lines to your `pom.xml` file:
     <dependency>
       <groupId>com.google.apis</groupId>
       <artifactId>google-api-services-addressvalidation</artifactId>
-      <version>v1-rev20241110-2.0.0</version>
+      <version>v1-rev20241120-2.0.0</version>
     </dependency>
   </dependencies>
 </project>
@@ -35,7 +35,7 @@ repositories {
   mavenCentral()
 }
 dependencies {
-  implementation 'com.google.apis:google-api-services-addressvalidation:v1-rev20241110-2.0.0'
+  implementation 'com.google.apis:google-api-services-addressvalidation:v1-rev20241120-2.0.0'
 }
 ```