Gradle plugin au.com.dius.pact with Kotlin DSL

[tglaeser]

How is the plugin supposed to be used with the Gradle Kotlin DSL?

I kind of got this working by declaring

plugins {
    ...
    id("au.com.dius.pact") version "4.5.8"
}

...

pact {
    serviceProviders {
        create("UsersProvider") {
            protocol = "https"
            host = "localhost"
            port = 443
            path = ""
            hasPactWith("UsersConsumer", closureOf<GradleConsumerInfo> {
                pactSource = project.layout.buildDirectory.dir("pacts").get().file("UsersConsumer-UsersProvider.json").asFile.toURI().toURL()
            } as Closure<GradleConsumerInfo>)
        }
    }
}

and executing gradle pactVerify:

> Task :pactVerify_UsersProvider
Execution optimizations have been disabled for task ':pactVerify_UsersProvider' to ensure correctness due to the following reasons:
  - In plugin 'au.com.dius.pact' type 'au.com.dius.pact.provider.gradle.PactVerificationTask' property 'testClasspathURL' has @Input annotation used on type 'java.net.URL' or a property of this type. Reason: Type 'java.net.URL' is not supported on properties annotated with @Input because Java Serialization can be inconsistent for this type. For more information, please refer to https://docs.gradle.org/8.3/userguide/validation_problems.html#unsupported_value_type in the Gradle documentation.

Verifying a pact between UsersConsumer and UsersProvider
  [from URL file:/home/user/project/build/pacts/UsersConsumer-UsersProvider.json]
  Given get-user-by-id-state
         WARNING: State Change ignored as there is no stateChange URL
  GET /v1/users/alice
    returns a response which
      has status code 200 (OK)
      has a matching body (OK)

NOTE: Skipping publishing of verification results as it has been disabled (pact.verifier.publishResults is not 'true')

Execution optimizations have been disabled for 1 invalid unit(s) of work during this build to ensure correctness.
Please consult deprecation warnings for more details.

BUILD SUCCESSFUL in 2s

But with problems:

• From above: What does WARNING: State Change ignored as there is no stateChange URL mean? I don't get this warning when executing the same verification via Junit 5.
• From above: Type 'java.net.URL' is not supported on properties annotated with @input because Java Serialization can be inconsistent for this type.
• Second parameter for hasPactWith is a Groovy closure; this doesn't work well with the Kotlin DSL, requires an unchecked cast.
• pactSource needs to be of type URL, this has been reported before. But why do I need to configure pactSource in the first place? The task could just look up all files under build/pacts and run verification on them.

[rholshausen]

What does WARNING: State Change ignored as there is no stateChange URL mean?

When executed in this manor, the state change handlers are invoked by using a URL. With JUnit, they are invoked by calling an annotated method on the JUnit test class. This warning is just stating the fact the you have not setup a state change handler URL, so none of the state changes will be executed.

[rholshausen]

From above: Type 'java.net.URL' is not supported on properties annotated with @input because Java Serialization can be inconsistent for this type.

There has been some Gradle improvements with the 4.6.x versions. You can try those. They also support Gradle 8.

[rholshausen]

pactSource needs to be of type URL, this has been reported before. But why do I need to configure pactSource in the first place? The task could just look up all files under build/pacts and run verification on them.

By design, the default way to use Pact is with a Pact Broker. This needs a URL and authentication to be configured.

[diktamxx]

pactSource needs to be of type URL, this has been reported before. But why do I need to configure pactSource in the first place? The task could just look up all files under build/pacts and run verification on them.

By design, the default way to use Pact is with a Pact Broker. This needs a URL and authentication to be configured.

I encountered the same problem. 🤔️ Can we avoid using the broker? I think introducing more components (such as the broker) actually represents a burden. For instance, the project might be organized in a Monorepo manner. In this case, it is much simpler to conduct tests directly using JSON files.

Additionally, I have noticed that the current document (https://docs.pact.io/implementation_guides/jvm/provider/gradle) seems not to be the latest version. The plugin used in the example is version "4.3.10". But as far as I know, the latest version at present is 4.7.x. I wonder if there are any differences in usage.