Skip to content

Commit

Permalink
chore: regenerate mybusinessverifications client
Browse files Browse the repository at this point in the history
  • Loading branch information
yoshi-code-bot committed Dec 21, 2024
1 parent 9f21475 commit 1803cc2
Show file tree
Hide file tree
Showing 4 changed files with 70 additions and 70 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ Add the following lines to your `pom.xml` file:
<dependency>
<groupId>com.google.apis</groupId>
<artifactId>google-api-services-mybusinessverifications</artifactId>
<version>v1-rev20230914-2.0.0</version>
<version>v1-rev20241120-2.0.0</version>
</dependency>
</dependencies>
</project>
Expand All @@ -35,7 +35,7 @@ repositories {
mavenCentral()
}
dependencies {
implementation 'com.google.apis:google-api-services-mybusinessverifications:v1-rev20230914-2.0.0'
implementation 'com.google.apis:google-api-services-mybusinessverifications:v1-rev20241120-2.0.0'
}
```

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -17,14 +17,14 @@
package com.google.api.services.mybusinessverifications.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 My Business Verifications API. For a detailed
Expand All @@ -40,18 +40,18 @@ public final class PostalAddress extends com.google.api.client.json.GenericJson
/**
* 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
Expand All @@ -60,9 +60,9 @@ public final class PostalAddress extends com.google.api.client.json.GenericJson
/**
* 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
Expand Down Expand Up @@ -100,7 +100,7 @@ public final class PostalAddress extends com.google.api.client.json.GenericJson
/**
* 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
Expand Down Expand Up @@ -134,9 +134,9 @@ public final class PostalAddress extends com.google.api.client.json.GenericJson

/**
* 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
Expand All @@ -153,18 +153,18 @@ public final class PostalAddress extends com.google.api.client.json.GenericJson
/**
* 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() {
Expand All @@ -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 PostalAddress setAddressLines(java.util.List<java.lang.String> addressLines) {
Expand All @@ -196,9 +196,9 @@ public PostalAddress setAddressLines(java.util.List<java.lang.String> addressLin
/**
* 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() {
Expand All @@ -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 PostalAddress setAdministrativeArea(java.lang.String administrativeArea) {
Expand Down Expand Up @@ -288,7 +288,7 @@ public PostalAddress 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() {
Expand All @@ -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 PostalAddress setPostalCode(java.lang.String postalCode) {
Expand Down Expand Up @@ -369,9 +369,9 @@ public PostalAddress 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() {
Expand All @@ -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 PostalAddress setSortingCode(java.lang.String sortingCode) {
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,8 @@

<groupId>com.google.apis</groupId>
<artifactId>google-api-services-mybusinessverifications</artifactId>
<version>v1-rev20230914-2.0.0</version>
<name>My Business Verifications API v1-rev20230914-2.0.0</name>
<version>v1-rev20241120-2.0.0</version>
<name>My Business Verifications API v1-rev20241120-2.0.0</name>
<packaging>jar</packaging>

<inceptionYear>2011</inceptionYear>
Expand Down Expand Up @@ -90,7 +90,7 @@
<windowtitle>My Business Verifications API ${project.version}</windowtitle>
<links>
<link>http://docs.oracle.com/javase/7/docs/api</link>
<link>https://googleapis.dev/java/google-http-client/1.45.0/</link>
<link>https://googleapis.dev/java/google-http-client/1.45.2/</link>
<link>https://googleapis.dev/java/google-oauth-client/1.36.0/</link>
<link>https://googleapis.dev/java/google-api-client/2.7.0/</link>
</links>
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ Add the following lines to your `pom.xml` file:
<dependency>
<groupId>com.google.apis</groupId>
<artifactId>google-api-services-mybusinessverifications</artifactId>
<version>v1-rev20230914-2.0.0</version>
<version>v1-rev20241120-2.0.0</version>
</dependency>
</dependencies>
</project>
Expand All @@ -35,7 +35,7 @@ repositories {
mavenCentral()
}
dependencies {
implementation 'com.google.apis:google-api-services-mybusinessverifications:v1-rev20230914-2.0.0'
implementation 'com.google.apis:google-api-services-mybusinessverifications:v1-rev20241120-2.0.0'
}
```

Expand Down

0 comments on commit 1803cc2

Please sign in to comment.