Download JAR files tagged by order with all dependencies

pact-jvm-consumer-groovy-v3 =========================== Groovy DSL for Pact JVM implementing V3 specification changes. ##Dependency The library is available on maven central using: * group-id = `au.com.dius` * artifact-id = `pact-jvm-consumer-groovy-v3_2.11` * version-id = `2.2.x` or `3.0.x` ##Usage Add the `pact-jvm-consumer-groovy-v3` library to your test class path. This provides a `PactMessageBuilder` class for you to use to define your pacts. If you are using gradle for your build, add it to your `build.gradle`: dependencies { testCompile 'au.com.dius:pact-jvm-consumer-groovy-v3_2.11:2.2.12' } ## Consumer test for a message consumer The `PactMessageBuilder` class provides a DSL for defining your message expectations. It works in much the same way as the `PactBuilder` class for Request-Response interactions. ### Step 1 - define the message expectations Create a test that uses the `PactMessageBuilder` to define a message expectation, and then call `run`. This will invoke the given closure with a message for each one defined in the pact. ```groovy def eventStream = new PactMessageBuilder().call { serviceConsumer 'messageConsumer' hasPactWith 'messageProducer' given 'order with id 10000004 exists' expectsToReceive 'an order confirmation message' withMetaData(type: 'OrderConfirmed') // Can define any key-value pairs here withContent(contentType: 'application/json') { type 'OrderConfirmed' audit { userCode 'messageService' } origin 'message-service' referenceId '10000004-2' timeSent: '2015-07-22T10:14:28+00:00' value { orderId '10000004' value '10.000000' fee '10.00' gst '15.00' } } } ``` ### Step 2 - call your message handler with the generated messages This example tests a message handler that gets messages from a Kafka topic. In this case the Pact message is wrapped as a Kafka `MessageAndMetadata`. ```groovy eventStream.run { Message message -> messageHandler.handleMessage(new MessageAndMetadata('topic', 1, new kafka.message.Message(message.contentsAsBytes()), 0, null, valueDecoder)) } ``` ### Step 3 - validate that the message was handled correctly ```groovy def order = orderRepository.getOrder('10000004') assert order.status == 'confirmed' assert order.value == 10.0 ``` ### Step 4 - Publish the pact file If the test was successful, a pact file would have been produced with the message from step 1.

pact-jvm-consumer-groovy-v3 =========================== Groovy DSL for Pact JVM implementing V3 specification changes. ##Dependency The library is available on maven central using: * group-id = `au.com.dius` * artifact-id = `pact-jvm-consumer-groovy-v3_2.11` * version-id = `2.2.x` or `3.0.x` ##Usage Add the `pact-jvm-consumer-groovy-v3` library to your test class path. This provides a `PactMessageBuilder` class for you to use to define your pacts. If you are using gradle for your build, add it to your `build.gradle`: dependencies { testCompile 'au.com.dius:pact-jvm-consumer-groovy-v3_2.11:2.2.12' } ## Consumer test for a message consumer The `PactMessageBuilder` class provides a DSL for defining your message expectations. It works in much the same way as the `PactBuilder` class for Request-Response interactions. ### Step 1 - define the message expectations Create a test that uses the `PactMessageBuilder` to define a message expectation, and then call `run`. This will invoke the given closure with a message for each one defined in the pact. ```groovy def eventStream = new PactMessageBuilder().call { serviceConsumer 'messageConsumer' hasPactWith 'messageProducer' given 'order with id 10000004 exists' expectsToReceive 'an order confirmation message' withMetaData(type: 'OrderConfirmed') // Can define any key-value pairs here withContent(contentType: 'application/json') { type 'OrderConfirmed' audit { userCode 'messageService' } origin 'message-service' referenceId '10000004-2' timeSent: '2015-07-22T10:14:28+00:00' value { orderId '10000004' value '10.000000' fee '10.00' gst '15.00' } } } ``` ### Step 2 - call your message handler with the generated messages This example tests a message handler that gets messages from a Kafka topic. In this case the Pact message is wrapped as a Kafka `MessageAndMetadata`. ```groovy eventStream.run { Message message -> messageHandler.handleMessage(new MessageAndMetadata('topic', 1, new kafka.message.Message(message.contentsAsBytes()), 0, null, valueDecoder)) } ``` ### Step 3 - validate that the message was handled correctly ```groovy def order = orderRepository.getOrder('10000004') assert order.status == 'confirmed' assert order.value == 10.0 ``` ### Step 4 - Publish the pact file If the test was successful, a pact file would have been produced with the message from step 1.

Axis2 is an effort to re-design and totally re-implement both Axis/Java and (eventually) Axis/C++ on a new architecture. Evolving from the now standard "handler chain" model which Axis1 pioneered, Axis2 is developing a more flexible pipeline architecture which can yet be managed and packaged in a more organized manner. This new design acknowledges the maturing of the Web services space in terms of new protocols such as WS-ReliableMessaging, WS-Security and WS-Addressing that are built on top of the base SOAP system. At the time Axis1 was designed, while it was fully expected that other protocols such as WS-ReliableMessaging would be built on top of it, there was not a proper extension architecture defined to enable clean composition of such layers. Thus, one of the key motivations for Axis2 is to provide a clean and simple environment for like Apache Sandesha and Apache WSS4J to layer on top of the base SOAP system. Another driving force for Axis2 as well as the move away from RPC oriented Web services towards more document-oriented, message style asynchronous service interactions. The Axis2 project is centered on a new representation for SOAP messages called AXIOM (AXIs Object Model). AXIOM consists of two parts: a complete XML Infoset representation and a SOAP Infoset representation on top of that. The XML Infoset representation provides a JDOM-like simple API but is built on a deferred model via a StAX-based (Streaming API for XML) pull parsing API. A key feature of AXIOM is that it allows one to stop building the XML tree and just access the pull stream directly; thus enabling both maximum flexibility and maximum performance. This approach allows us to support multiple levels of abstraction for consuming and offering Web services: using plain AXIOM, using generated code and statically data-bound data types and so on. At the time of Axis1's design, RPC-style, synchronous, request-response interactions were the order of the day for Web services. Today service interactions are much more message -oriented and exploit many different message exchange patterns. The Axis2 engine architecture is careful to not build in any assumptions of request-response patterns to ensure that it can be used easily to support arbitrary message exchange patterns.

This is the main aggregator for all gwt submodules. All gwt-specific code resides here. Submodules should avoid inheriting from each other unless necessary. This goes for maven structure and gwt.xml structure. The super module is where our jre emulation layer and super-source live; all modules should inherit super, and a minimum of other modules. Some modules, like injection, are fulfilling an api in the core module, and should be accessed only through core service interfaces. Other modules, like reflection, are capable of being standalone inherits, but can benefit from core utilities like injection, so, two (or more) .gwt.xml modules may be provided. As XApi nears 1.0, all submodules will be routinely stitched together into an uber-jar, in order to have a single jar with a single gwt module that can provide all of the services at once. Internal projects will never use the uber jar, to help maintain modularity, but external projects that want to use more than one service will certainly prefer inheriting one artifact, instead of twelve. When distributed in uber-jar format, it will likely be necessary for either the uber jar, or just xapi-gwt-api.jar to appear before gwt-dev on your compile-time classpath. If using gwt-maven-plugin, the gwtFirstOnClasspath option may become problematic. If so, we will provide a forked gwt-plugin to make sure our compiler enhancements are included in the build process. There is also work going on to make a super-source-everything plugin, which will use maven to find source files, and generate synthetic .gwt.xml for you, as part of an effort to create a wholly unified programming environment. In addition to java-to-javascript, we intend to compile java-to-java and possibly other languages, like go; imagine implementing gwt deferred binding to eliminate cross-platform differences between server environments, or operating systems, or versions of a platform, or anywhere else a core api needs to bind to multiple implementations, depending on the runtime environment.

Alphatier is a resource management library. It is designed to allow different schedulers to share the resources of a pool of executors in order to execute tasks with those. Read the [detailed documentation](#io.alphatier.pools) below to get an in-depth understanding. ## License Copyright &copy; 2014 [Tobias Sarnowski](mailto:[email protected]), [Willi Schönborn](mailto:[email protected]) Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ## Usage The library is written in [Clojure](http://clojure.org/) and is available in the [central Maven repository](https://repo1.maven.org/maven2/io/alphatier/alphatier/): <dependency> <groupId>io.alphatier</groupId> <artifactId>alphatier</artifactId> <version>0.3.0</version> </dependency> The library is written in pure Clojure without [ahead-of-time compilation](http://clojure.org/compilation). This means, that the library does not contain any *.class files. If you work with Clojure, this is not a problem but if you like to use the library from another JVM language (like Java, Scala or Groovy), you can use [Clojure's built-in tools](http://clojure.org/java_interop#Java%20Interop-Calling%20Clojure%20From%20Java) for interoperability or try our Java library: [https://github.com/sarnowski/alphatier-java](https://github.com/sarnowski/alphatier-java) ### Development If you like to change this library, please have a look at the [README](README.md). Development is done via [Github](https://github.com/sarnowski/alphatier).

BEhavioural Agents Simple Testing Tool - BEAST Tool The aim of this project is the development of a system which allows Behavior Driven Development (BDD) in Multi-Agent Systems (MAS), to make testing practices more accessible and intuitive to everybody. In one hand, in order to let tests be writable by newcomers and experts alike, system must allow the redaction of tests in plain text, because client does not need to have knowledge of our code. This plain text will be traduced to software later. The definition of test will be realized with the terminology Given-When-Then, which allows trace an easy guide of the behavior of a given scenario when something happened. In the other hand, due to the complexity of MAS, making unit testing of an agent that needs the interaction with others is almost impossible until the whole system is finished. This implies to leave testing issues to the end of the project, generating big troubles in case of malfunction. Consequently, its necessary to carry out a tool to allow the creation of mock agents and to perform tests during the whole development process. Therefore another objective of our systems is to include a mocking tool which permits testing continuously. Definitively, our tool allows the testing of any MAS in the development process, increasing its modularity and decreasing its elaboration and testing cost. These tests will be written in plain text so that anyone would be able to understand them. For further reading, a paper published in ITMAS2012 workshop can be found in: http://scholar.google.es/citations?view_op=view_citation&hl=es&user=mT3KgXUAAAAJ&citation_for_view=mT3KgXUAAAAJ:Tyk-4Ss8FVUC

Maven plugin to verify a provider ================================= Maven plugin for verifying pacts against a provider. The Maven plugin provides a `verify` goal which will verify all configured pacts against your provider. ## To Use It ### 1. Add the pact-jvm-provider-maven plugin to your `build` section of your pom file. ```xml &lt;build&gt; [...] &lt;plugins&gt; [...] &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;/plugin&gt; [...] &lt;/plugins&gt; [...] &lt;/build&gt; ``` ### 2. Define the pacts between your consumers and providers You define all the providers and consumers within the configuration element of the maven plugin. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;!-- You can define as many as you need, but each must have a unique name --&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;!-- All the provider properties are optional, and have sensible defaults (shown below) --&gt; &lt;protocol&gt;http&lt;/protocol&gt; &lt;host&gt;localhost&lt;/host&gt; &lt;port&gt;8080&lt;/port&gt; &lt;path&gt;/&lt;/path&gt; &lt;consumers&gt; &lt;!-- Again, you can define as many consumers for each provider as you need, but each must have a unique name --&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;!-- currently supports a file path using pactFile or a URL using pactUrl --&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### 3. Execute `mvn pact:verify` You will have to have your provider running for this to pass. ## Verifying all pact files in a directory for a provider You can specify a directory that contains pact files, and the Pact plugin will scan for all pact files that match that provider and define a consumer for each pact file in the directory. Consumer name is read from contents of pact file. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;!-- You can define as many as you need, but each must have a unique name --&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;!-- All the provider properties are optional, and have sensible defaults (shown below) --&gt; &lt;protocol&gt;http&lt;/protocol&gt; &lt;host&gt;localhost&lt;/host&gt; &lt;port&gt;8080&lt;/port&gt; &lt;path&gt;/&lt;/path&gt; &lt;pactFileDirectory&gt;path/to/pacts&lt;/pactFileDirectory&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### Verifying all pact files from multiple directories for a provider [3.5.18+] If you want to specify multiple directories, you can use `pactFileDirectories`. The plugin will only fail the build if no pact files are loaded after processing all the directories in the list. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.18&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;pactFileDirectories&gt; &lt;pactFileDirectory&gt;path/to/pacts1&lt;/pactFileDirectory&gt; &lt;pactFileDirectory&gt;path/to/pacts2&lt;/pactFileDirectory&gt; &lt;/pactFileDirectories&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Enabling insecure SSL For providers that are running on SSL with self-signed certificates, you need to enable insecure SSL mode by setting `&lt;insecure&gt;true&lt;/insecure&gt;` on the provider. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;pactFileDirectory&gt;path/to/pacts&lt;/pactFileDirectory&gt; &lt;insecure&gt;true&lt;/insecure&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Specifying a custom trust store For environments that are running their own certificate chains: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;pactFileDirectory&gt;path/to/pacts&lt;/pactFileDirectory&gt; &lt;trustStore&gt;relative/path/to/trustStore.jks&lt;/trustStore&gt; &lt;trustStorePassword&gt;changeit&lt;/trustStorePassword&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` `trustStore` is either relative to the current working (build) directory. `trustStorePassword` defaults to `changeit`. NOTE: The hostname will still be verified against the certificate. ## Modifying the requests before they are sent Sometimes you may need to add things to the requests that can&apos;t be persisted in a pact file. Examples of these would be authentication tokens, which have a small life span. The Pact Maven plugin provides a request filter that can be set to a Groovy script on the provider that will be called before the request is made. This script will receive the HttpRequest bound to a variable named `request` prior to it being executed. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;requestFilter&gt; // This is a Groovy script that adds an Authorization header to each request request.addHeader(&apos;Authorization&apos;, &apos;oauth-token eyJhbGciOiJSUzI1NiIsIm...&apos;) &lt;/requestFilter&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` __*Important Note:*__ You should only use this feature for things that can not be persisted in the pact file. By modifying the request, you are potentially modifying the contract from the consumer tests! ## Modifying the HTTP Client Used The default HTTP client is used for all requests to providers (created with a call to `HttpClients.createDefault()`). This can be changed by specifying a closure assigned to createClient on the provider that returns a CloseableHttpClient. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;createClient&gt; // This is a Groovy script that will enable the client to accept self-signed certificates import org.apache.http.ssl.SSLContextBuilder import org.apache.http.conn.ssl.NoopHostnameVerifier import org.apache.http.impl.client.HttpClients HttpClients.custom().setSSLHostnameVerifier(new NoopHostnameVerifier()) .setSslcontext(new SSLContextBuilder().loadTrustMaterial(null, { x509Certificates, s -&gt; true }) .build()) .build() &lt;/createClient&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Turning off URL decoding of the paths in the pact file By default the paths loaded from the pact file will be decoded before the request is sent to the provider. To turn this behaviour off, set the system property `pact.verifier.disableUrlPathDecoding` to `true`. __*Important Note:*__ If you turn off the url path decoding, you need to ensure that the paths in the pact files are correctly encoded. The verifier will not be able to make a request with an invalid encoded path. ## Plugin Properties The following plugin properties can be specified with `-Dproperty=value` on the command line or in the configuration section: |Property|Description| |--------|-----------| |pact.showStacktrace|This turns on stacktrace printing for each request. It can help with diagnosing network errors| |pact.showFullDiff|This turns on displaying the full diff of the expected versus actual bodies| |pact.filter.consumers|Comma separated list of consumer names to verify| |pact.filter.description|Only verify interactions whose description match the provided regular expression| |pact.filter.providerState|Only verify interactions whose provider state match the provided regular expression. An empty string matches interactions that have no state| |pact.verifier.publishResults|Publishing of verification results will be skipped unless this property is set to &apos;true&apos; [version 3.5.18+]| |pact.matching.wildcard|Enables matching of map values ignoring the keys when this property is set to &apos;true&apos;| Example in the configuration section: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;configuration&gt; &lt;pact.showStacktrace&gt;true&lt;/pact.showStacktrace&gt; &lt;/configuration&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Provider States For each provider you can specify a state change URL to use to switch the state of the provider. This URL will receive the providerState description and parameters from the pact file before each interaction via a POST. The stateChangeUsesBody controls if the state is passed in the request body or as query parameters. These values can be set at the provider level, or for a specific consumer. Consumer values take precedent if both are given. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;stateChangeUsesBody&gt;false&lt;/stateChangeUsesBody&gt; &lt;!-- defaults to true --&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChangeForConsumer1&lt;/stateChangeUrl&gt; &lt;stateChangeUsesBody&gt;false&lt;/stateChangeUsesBody&gt; &lt;!-- defaults to true --&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` If the `stateChangeUsesBody` is not specified, or is set to true, then the provider state description and parameters will be sent as JSON in the body of the request. If it is set to false, they will passed as query parameters. As for normal requests (see Modifying the requests before they are sent), a state change request can be modified before it is sent. Set `stateChangeRequestFilter` to a Groovy script on the provider that will be called before the request is made. #### Teardown calls for state changes You can enable teardown state change calls by setting the property `&lt;stateChangeTeardown&gt;true&lt;/stateChangeTeardown&gt;` on the provider. This will add an `action` parameter to the state change call. The setup call before the test will receive `action=setup`, and then a teardown call will be made afterwards to the state change URL with `action=teardown`. ## Verifying pact files from a pact broker You can setup your build to validate against the pacts stored in a pact broker. The pact plugin will query the pact broker for all consumers that have a pact with the provider based on its name. To use it, just configure the `pactBrokerUrl` or `pactBroker` value for the provider with the base URL to the pact broker. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBrokerUrl&gt;http://pact-broker:5000/&lt;/pactBrokerUrl&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### Verifying pacts from an authenticated pact broker If your pact broker requires authentication (basic authentication is only supported), you can configure the username and password to use by configuring the `authentication` element of the `pactBroker` element of your provider. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBroker&gt; &lt;url&gt;http://pactbroker:1234&lt;/url&gt; &lt;authentication&gt; &lt;username&gt;test&lt;/username&gt; &lt;password&gt;test&lt;/password&gt; &lt;/authentication&gt; &lt;/pactBroker&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` #### Using the Maven servers configuration [version 3.5.6+] From version 3.5.6, you can use the servers setup in the Maven settings. To do this, setup a server as per the [Maven Server Settings](https://maven.apache.org/settings.html#Servers). Then set the server ID in the pact broker configuration in your POM. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.6&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBroker&gt; &lt;url&gt;http://pactbroker:1234&lt;/url&gt; &lt;serverId&gt;test-pact-broker&lt;/serverId&gt; &lt;!-- This must match the server id in the maven settings --&gt; &lt;/pactBroker&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### Verifying pacts from an pact broker that match particular tags If your pacts in your pact broker have been tagged, you can set the tags to fetch by configuring the `tags` element of the `pactBroker` element of your provider. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBroker&gt; &lt;url&gt;http://pactbroker:1234&lt;/url&gt; &lt;tags&gt; &lt;tag&gt;TEST&lt;/tag&gt; &lt;tag&gt;DEV&lt;/tag&gt; &lt;/tags&gt; &lt;/pactBroker&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` This example will fetch and validate the pacts for the TEST and DEV tags. ## Filtering the interactions that are verified You can filter the interactions that are run using three properties: `pact.filter.consumers`, `pact.filter.description` and `pact.filter.providerState`. Adding `-Dpact.filter.consumers=consumer1,consumer2` to the command line or configuration section will only run the pact files for those consumers (consumer1 and consumer2). Adding `-Dpact.filter.description=a request for payment.*` will only run those interactions whose descriptions start with &apos;a request for payment&apos;. `-Dpact.filter.providerState=.*payment` will match any interaction that has a provider state that ends with payment, and `-Dpact.filter.providerState=` will match any interaction that does not have a provider state. ## Not failing the build if no pact files are found [version 3.5.19+] By default, if there are no pact files to verify, the plugin will raise an exception. This is to guard against false positives where the build is passing but nothing has been verified due to mis-configuration. To disable this behaviour, set the `failIfNoPactsFound` parameter to `false`. # Verifying a message provider The Maven plugin has been updated to allow invoking test methods that can return the message contents from a message producer. To use it, set the way to invoke the verification to `ANNOTATED_METHOD`. This will allow the pact verification task to scan for test methods that return the message contents. Add something like the following to your maven pom file: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;messageProvider&lt;/name&gt; &lt;verificationType&gt;ANNOTATED_METHOD&lt;/verificationType&gt; &lt;!-- packagesToScan is optional, but leaving it out will result in the entire test classpath being scanned. Set it to the packages where your annotated test method can be found. --&gt; &lt;packagesToScan&gt; &lt;packageToScan&gt;au.com.example.messageprovider.*&lt;/packageToScan&gt; &lt;/packagesToScan&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/messageprovider-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` Now when the pact verify task is run, will look for methods annotated with `@PactVerifyProvider` in the test classpath that have a matching description to what is in the pact file. ```groovy class ConfirmationKafkaMessageBuilderTest { @PactVerifyProvider(&apos;an order confirmation message&apos;) String verifyMessageForOrder() { Order order = new Order() order.setId(10000004) order.setExchange(&apos;ASX&apos;) order.setSecurityCode(&apos;CBA&apos;) order.setPrice(BigDecimal.TEN) order.setUnits(15) order.setGst(new BigDecimal(&apos;15.0&apos;)) odrer.setFees(BigDecimal.TEN) def message = new ConfirmationKafkaMessageBuilder() .withOrder(order) .build() JsonOutput.toJson(message) } } ``` It will then validate that the returned contents matches the contents for the message in the pact file. ## Changing the class path that is scanned By default, the test classpath is scanned for annotated methods. You can override this by setting the `classpathElements` property: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;messageProvider&lt;/name&gt; &lt;verificationType&gt;ANNOTATED_METHOD&lt;/verificationType&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/messageprovider-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;classpathElements&gt; &lt;classpathElement&gt; build/classes/test &lt;/classpathElement&gt; &lt;/classpathElements&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` # Publishing pact files to a pact broker The pact maven plugin provides a `publish` mojo that can publish all pact files in a directory to a pact broker. To use it, you need to add a publish configuration to the POM that defines the directory where the pact files are and the URL to the pact broker. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;pactDirectory&gt;path/to/pact/files&lt;/pactDirectory&gt; &lt;!-- Defaults to ${project.build.directory}/pacts --&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;projectVersion&gt;1.0.100&lt;/projectVersion&gt; &lt;!-- Defaults to ${project.version} --&gt; &lt;trimSnapshot&gt;true&lt;/trimSnapshot&gt; &lt;!-- Defaults to false --&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` You can now execute `mvn pact:publish` to publish the pact files. _NOTE:_ The pact broker requires a version for all published pacts. The `publish` task will use the version of the project by default, but can be overwritten with the `projectVersion` property. Make sure you have set one otherwise the broker will reject the pact files. _NOTE_: By default, the pact broker has issues parsing `SNAPSHOT` versions. You can configure the publisher to automatically remove `-SNAPSHOT` from your version number by setting `trimSnapshot` to true. This setting does not modify non-snapshot versions. You can set any tags that the pacts should be published with by setting the `tags` list property (version 3.5.12+). A common use of this is setting the tag to the current source control branch. This supports using pact with feature branches. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.12&lt;/version&gt; &lt;configuration&gt; &lt;pactDirectory&gt;path/to/pact/files&lt;/pactDirectory&gt; &lt;!-- Defaults to ${project.build.directory}/pacts --&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;projectVersion&gt;1.0.100&lt;/projectVersion&gt; &lt;!-- Defaults to ${project.version} --&gt; &lt;tags&gt; &lt;tag&gt;feature/feature_name&lt;/tag&gt; &lt;/tags&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Publishing to an authenticated pact broker For an authenticated pact broker, you can pass in the credentials with the `pactBrokerUsername` and `pactBrokerPassword` properties. Currently it only supports basic authentication. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;pactBrokerUsername&gt;USERNAME&lt;/pactBrokerUsername&gt; &lt;pactBrokerPassword&gt;PASSWORD&lt;/pactBrokerPassword&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` #### Using the Maven servers configuration [version 3.5.6+] From version 3.5.6, you can use the servers setup in the Maven settings. To do this, setup a server as per the [Maven Server Settings](https://maven.apache.org/settings.html#Servers). Then set the server ID in the pact broker configuration in your POM. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.5.19&lt;/version&gt; &lt;configuration&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;pactBrokerServerId&gt;test-pact-broker&lt;/pactBrokerServerId&gt; &lt;!-- This must match the server id in the maven settings --&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Excluding pacts from being published [version 3.5.19+] You can exclude some of the pact files from being published by providing a list of regular expressions that match against the base names of the pact files. For example: ```groovy pact { publish { pactBrokerUrl = &apos;https://mypactbroker.com&apos; excludes = [ &apos;.*\\-\\d+$&apos; ] // exclude all pact files that end with a dash followed by a number in the name } } ``` ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.19&lt;/version&gt; &lt;configuration&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;excludes&gt; &lt;exclude&gt;.*\\-\\d+$&lt;/exclude&gt; &lt;!-- exclude pact files where the name ends in a dash followed by a number --&gt; &lt;/excludes&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` # Publishing verification results to a Pact Broker [version 3.5.4+] For pacts that are loaded from a Pact Broker, the results of running the verification can be published back to the broker against the URL for the pact. You will be able to then see the result on the Pact Broker home screen. To turn on the verification publishing, set the system property `pact.verifier.publishResults` to `true` in the pact maven plugin, not surefire, configuration. # Enabling other verification reports [version 3.5.20+] By default the verification report is written to the console. You can also enable a JSON or Markdown report by setting the `reports` configuration list. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.20&lt;/version&gt; &lt;configuration&gt; &lt;reports&gt; &lt;report&gt;console&lt;/report&gt; &lt;report&gt;json&lt;/report&gt; &lt;report&gt;markdown&lt;/report&gt; &lt;/reports&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` These reports will be written to `target/reports/pact`.

# Pact junit runner ## Overview Library provides ability to play contract tests against a provider service in JUnit fashionable way. Supports: - Out-of-the-box convenient ways to load pacts - Easy way to change assertion strategy - **org.junit.BeforeClass**, **org.junit.AfterClass** and **org.junit.ClassRule** JUnit annotations, that will be run once - before/after whole contract test suite. - **org.junit.Before**, **org.junit.After** and **org.junit.Rule** JUnit annotations, that will be run before/after each test of an interaction. - **au.com.dius.pact.provider.junit.State** custom annotation - before each interaction that requires a state change, all methods annotated by `@State` with appropriate the state listed will be invoked. These methods must either take no parameters or a single Map parameter. ## Example of HTTP test ```java @RunWith(PactRunner.class) // Say JUnit to run tests with custom Runner @Provider(&quot;myAwesomeService&quot;) // Set up name of tested provider @PactFolder(&quot;pacts&quot;) // Point where to find pacts (See also section Pacts source in documentation) public class ContractTest { // NOTE: this is just an example of embedded service that listens to requests, you should start here real service @ClassRule //Rule will be applied once: before/after whole contract test suite public static final ClientDriverRule embeddedService = new ClientDriverRule(8332); @BeforeClass //Method will be run once: before whole contract test suite public static void setUpService() { //Run DB, create schema //Run service //... } @Before //Method will be run before each test of interaction public void before() { // Rest data // Mock dependent service responses // ... embeddedService.addExpectation( onRequestTo(&quot;/data&quot;), giveEmptyResponse() ); } @State(&quot;default&quot;, &quot;no-data&quot;) // Method will be run before testing interactions that require &quot;default&quot; or &quot;no-data&quot; state public void toDefaultState() { // Prepare service before interaction that require &quot;default&quot; state // ... System.out.println(&quot;Now service in default state&quot;); } @State(&quot;with-data&quot;) // Method will be run before testing interactions that require &quot;with-data&quot; state public void toStateWithData(Map data) { // Prepare service before interaction that require &quot;with-data&quot; state. The provider state data will be passed // in the data parameter // ... System.out.println(&quot;Now service in state using data &quot; + data); } @TestTarget // Annotation denotes Target that will be used for tests public final Target target = new HttpTarget(8332); // Out-of-the-box implementation of Target (for more information take a look at Test Target section) } ``` ## Example of AMQP Message test ```java @RunWith(PactRunner.class) // Say JUnit to run tests with custom Runner @Provider(&quot;myAwesomeService&quot;) // Set up name of tested provider @PactBroker(host=&quot;pactbroker&quot;, port = &quot;80&quot;) public class ConfirmationKafkaContractTest { @TestTarget // Annotation denotes Target that will be used for tests public final Target target = new AmqpTarget(); // Out-of-the-box implementation of Target (for more information take a look at Test Target section) @BeforeClass //Method will be run once: before whole contract test suite public static void setUpService() { //Run DB, create schema //Run service //... } @Before //Method will be run before each test of interaction public void before() { // Message data preparation // ... } @PactVerifyProvider(&apos;an order confirmation message&apos;) String verifyMessageForOrder() { Order order = new Order() order.setId(10000004) order.setPrice(BigDecimal.TEN) order.setUnits(15) def message = new ConfirmationKafkaMessageBuilder() .withOrder(order) .build() JsonOutput.toJson(message) } } ``` ## Provider state callback methods For the provider states in the pact being verified, you can define methods to be invoked to setup the correct state for each interaction. Just annotate a method with the `au.com.dius.pact.provider.junit.State` annotation and the method will be invoked before the interaction is verified. For example: ```java @State(&quot;SomeProviderState&quot;) // Must match the state description in the pact file public void someProviderState() { // Do what you need to set the correct state } ``` If there are parameters in the pact file, just add a Map parameter to the method to be able to access those parameters. ```java @State(&quot;SomeProviderState&quot;) public void someProviderState(Map&lt;String, Object&gt; providerStateParameters) { // Do what you need to set the correct state } ``` ### Provider state teardown methods [3.5.22+] If you need to tear down your provider state, you can annotate a method with the `@State` annotation with the action set to `StateChangeAction.TEARDOWN` and it will be invoked after the interaction is verified. ```java @State(&quot;SomeProviderState&quot;, action = StateChangeAction.TEARDOWN) public void someProviderStateCleanup() { // Do what you need to to teardown the state } ``` ## Pact source The Pact runner will automatically collect pacts based on annotations on the test class. For this purpose there are 3 out-of-the-box options (files from a directory, files from a set of URLs or a pact broker) or you can easily add your own Pact source. If you need to load a single pact file from the file system, use the `PactUrl` with the URL set to the file path. **Note:** You can only define one source of pacts per test class. ### Download pacts from a pact-broker To use pacts from a Pact Broker, annotate the test class with `@PactBroker(host=&quot;host.of.pact.broker.com&quot;, port = &quot;80&quot;)`. From _version 3.2.2/2.4.3+_ you can also specify the protocol, which defaults to &quot;http&quot;. The pact broker will be queried for all pacts with the same name as the provider annotation. For example, test all pacts for the &quot;Activity Service&quot; in the pact broker: ```java @RunWith(PactRunner.class) @Provider(&quot;Activity Service&quot;) @PactBroker(host = &quot;localhost&quot;, port = &quot;80&quot;) public class PactJUnitTest { @TestTarget public final Target target = new HttpTarget(5050); } ``` #### _Version 3.2.3/2.4.4+_ - Using Java System properties The pact broker loader was updated to allow system properties to be used for the hostname, port or protocol. The port was changed to a string to allow expressions to be set. To use a system property or environment variable, you can place the property name in `${}` expression de-markers: ```java @PactBroker(host=&quot;${pactbroker.hostname}&quot;, port = &quot;80&quot;) ``` You can provide a default value by separating the property name with a colon (`:`): ```java @PactBroker(host=&quot;${pactbroker.hostname:localhost}&quot;, port = &quot;80&quot;) ``` #### _Version 3.5.3+_ - More Java System properties The default values of the `@PactBroker` annotation now enable variable interpolation. The following keys may be managed through the environment * `pactbroker.host` * `pactbroker.port` * `pactbroker.protocol` * `pactbroker.tags` (comma separated) * `pactbroker.auth.scheme` * `pactbroker.auth.username` * `pactbroker.auth.password` #### _Version 3.2.4/2.4.6+_ - Using tags with the pact broker The pact broker allows different versions to be tagged. To load all the pacts: ```java @PactBroker(host=&quot;pactbroker&quot;, port = &quot;80&quot;, tags = {&quot;latest&quot;, &quot;dev&quot;, &quot;prod&quot;}) ``` The default value for tags is `latest` which is not actually a tag but instead corresponds to the latest version ignoring the tags. If there are multiple consumers matching the name specified in the provider annotation then the latest pact for each of the consumers is loaded. For any other value the latest pact tagged with the specified tag is loaded. Specifying multiple tags is an OR operation. For example if you specify `tags = {&quot;dev&quot;, &quot;prod&quot;}` then both the latest pact file tagged with `dev` and the latest pact file taggged with `prod` is loaded. #### _Version 3.3.4/2.4.19+_ - Using basic auth with the with the pact broker You can use basic authentication with the `@PactBroker` annotation by setting the `authentication` value to a `@PactBrokerAuth` annotation. For example: ```java @PactBroker(host = &quot;${pactbroker.url:localhost}&quot;, port = &quot;1234&quot;, tags = {&quot;latest&quot;, &quot;prod&quot;, &quot;dev&quot;}, authentication = @PactBrokerAuth(username = &quot;test&quot;, password = &quot;test&quot;)) ``` The `username` and `password` values also take Java system property expressions. ### Pact Url To use pacts from urls annotate the test class with ```java @PactUrl(urls = {&quot;http://build.server/zoo_app-animal_service.json&quot;} ) ``` If you need to load a single pact file from the file system, you can use the `PactUrl` with the URL set to the file path. ### Pact folder To use pacts from a resource folder of the project annotate test class with ```java @PactFolder(&quot;subfolder/in/resource/directory&quot;) ``` ### Custom pacts source It&apos;s possible to use a custom Pact source. For this, implement interface `au.com.dius.pact.provider.junit.loader.PactLoader` and annotate the test class with `@PactSource(MyOwnPactLoader.class)`. **Note:** class `MyOwnPactLoader` must have a default empty constructor or a constructor with one argument of class `Class` which at runtime will be the test class so you can get custom annotations of test class. ### Filtering the interactions that are verified [version 3.5.3+] By default, the pact runner will verify all pacts for the given provider. You can filter the pacts and interactions by the following methods. #### Filtering by Consumer You can run only those pacts for a particular consumer by adding a `@Consumer` annotation to the test class. For example: ```java @RunWith(PactRunner.class) @Provider(&quot;Activity Service&quot;) @Consumer(&quot;Activity Consumer&quot;) @PactBroker(host = &quot;localhost&quot;, port = &quot;80&quot;) public class PactJUnitTest { @TestTarget public final Target target = new HttpTarget(5050); } ``` #### Filtering by Provider State You can filter the interactions that are executed by adding a `@PactFilter` annotation to your test class. The pact filter annotation will then only verify interactions that have a matching provider state. You can provide multiple states to match with. For example: ```java @RunWith(PactRunner.class) @Provider(&quot;Activity Service&quot;) @PactBroker(host = &quot;localhost&quot;, port = &quot;80&quot;) @PactFilter(&apos;Activity 100 exists in the database&apos;) public class PactJUnitTest { @TestTarget public final Target target = new HttpTarget(5050); } ``` You can also use regular expressions with the filter [version 3.5.3+]. For example: ```java @RunWith(PactRunner.class) @PactFilter(&apos;Activity \\d+ exists in the database&apos;) public class PactJUnitTest { } ``` ### Setting the test to not fail when no pacts are found [version 3.5.3+] By default the pact runner will fail the verification test if no pact files are found to verify. To change the failure into a warning, add a `@IgnoreNoPactsToVerify` annotation to your test class. #### Ignoring IO errors loading pact files [version 3.5.24+] You can also set the test to ignore any IO and parser exceptions when loading the pact files by setting the `ignoreIoErrors` attribute on the annotation to `&quot;true&quot;` or setting the JVM system property `pact.verification.ignoreIoErrors` to `true`. ** WARNING! Do not enable this on your CI server, as this could result in your build passing with no providers having been verified due to a configuration error. ** ## Test target The field in test class of type `au.com.dius.pact.provider.junit.target.Target` annotated with `au.com.dius.pact.provider.junit.target.TestTarget` will be used for actual Interaction execution and asserting of contract. **Note:** there must be exactly 1 such field, otherwise an `InitializationException` will be thrown. ### HttpTarget `au.com.dius.pact.provider.junit.target.HttpTarget` - out-of-the-box implementation of `au.com.dius.pact.provider.junit.target.Target` that will play pacts as http request and assert response from service by matching rules from pact. _Version 3.2.2/2.4.3+_ you can also specify the protocol, defaults to &quot;http&quot;. ### AmqpTarget `au.com.dius.pact.provider.junit.target.AmqpTarget` - out-of-the-box implementation of `au.com.dius.pact.provider.junit.target.Target` that will play pacts as an AMQP message and assert response from service by matching rules from pact. #### Modifying the requests before they are sent [Version 3.2.3/2.4.5+] Sometimes you may need to add things to the requests that can&apos;t be persisted in a pact file. Examples of these would be authentication tokens, which have a small life span. The HttpTarget supports request filters by annotating methods on the test class with `@TargetRequestFilter`. These methods must be public void methods that take a single HttpRequest parameter. For example: ```java @TargetRequestFilter public void exampleRequestFilter(HttpRequest request) { request.addHeader(&quot;Authorization&quot;, &quot;OAUTH hdsagasjhgdjashgdah...&quot;); } ``` __*Important Note:*__ You should only use this feature for things that can not be persisted in the pact file. By modifying the request, you are potentially modifying the contract from the consumer tests! #### Turning off URL decoding of the paths in the pact file [version 3.3.3+] By default the paths loaded from the pact file will be decoded before the request is sent to the provider. To turn this behaviour off, set the system property `pact.verifier.disableUrlPathDecoding` to `true`. __*Important Note:*__ If you turn off the url path decoding, you need to ensure that the paths in the pact files are correctly encoded. The verifier will not be able to make a request with an invalid encoded path. ### Custom Test Target It&apos;s possible to use custom `Target`, for that interface `Target` should be implemented and this class can be used instead of `HttpTarget`. # Verification Reports [versions 3.2.7/2.4.9+] The default test behaviour is to display the verification being done to the console, and pass or fail the test via the normal JUnit mechanism. From versions 3.2.7/2.4.9+, additional reports can be generated from the tests. ## Enabling additional reports via annotations on the test classes A `@VerificationReports` annotation can be added to any pact test class which will control the verification output. The annotation takes a list report types and an optional report directory (defaults to &quot;target/pact/reports&quot;). The currently supported report types are `console`, `markdown` and `json`. For example: ```java @VerificationReports({&quot;console&quot;, &quot;markdown&quot;}) public class MyPactTest { ``` will enable the markdown report in addition to the normal console output. And, ```java @VerificationReports(value = {&quot;markdown&quot;}, reportDir = &quot;/myreports&quot;) public class MyPactTest { ``` will disable the normal console output and write the markdown reports to &quot;/myreports&quot;. ## Enabling additional reports via Java system properties or environment variables The additional reports can also be enabled with Java System properties or environment variables. The following two properties have been introduced: `pact.verification.reports` and `pact.verification.reportDir`. `pact.verification.reports` is the comma separated list of report types to enable (e.g. `console,json,markdown`). `pact.verification.reportDir` is the directory to write reports to (defaults to &quot;target/pact/reports&quot;). ## Additional Reports The following report types are available in addition to console output (`console`, which is enabled by default): `markdown`, `json`. You can also provide a fully qualified classname as report so custom reports are also supported. This class must implement `au.com.dius.pact.provider.reporters.VerifierReporter` interface in order to be correct custom implementation of a report. # Publishing verification results to a Pact Broker [version 3.5.4+] For pacts that are loaded from a Pact Broker, the results of running the verification can be published back to the broker against the URL for the pact. You will be able to see the result on the Pact Broker home screen. You need to set the version of the provider that is verified using the `pact.provider.version` system property. To enable publishing of results, set the property `pact.verifier.publishResults` to `true` [version 3.5.18+].

Maven plugin to verify a provider [version 2.1.9+] ================================================== Maven plugin for verifying pacts against a provider. The Maven plugin provides a `verify` goal which will verify all configured pacts against your provider. ## To Use It ### 1. Add the pact-jvm-provider-maven plugin to your `build` section of your pom file. ```xml &lt;build&gt; [...] &lt;plugins&gt; [...] &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;/plugin&gt; [...] &lt;/plugins&gt; [...] &lt;/build&gt; ``` ### 2. Define the pacts between your consumers and providers You define all the providers and consumers within the configuration element of the maven plugin. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;!-- You can define as many as you need, but each must have a unique name --&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;!-- All the provider properties are optional, and have sensible defaults (shown below) --&gt; &lt;protocol&gt;http&lt;/protocol&gt; &lt;host&gt;localhost&lt;/host&gt; &lt;port&gt;8080&lt;/port&gt; &lt;path&gt;/&lt;/path&gt; &lt;consumers&gt; &lt;!-- Again, you can define as many consumers for each provider as you need, but each must have a unique name --&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;!-- currently supports a file path using pactFile or a URL using pactUrl --&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### 3. Execute `mvn pact:verify` You will have to have your provider running for this to pass. ## Verifying all pact files in a directory for a provider. [2.1.10+] You can specify a directory that contains pact files, and the Pact plugin will scan for all pact files that match that provider and define a consumer for each pact file in the directory. Consumer name is read from contents of pact file. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;!-- You can define as many as you need, but each must have a unique name --&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;!-- All the provider properties are optional, and have sensible defaults (shown below) --&gt; &lt;protocol&gt;http&lt;/protocol&gt; &lt;host&gt;localhost&lt;/host&gt; &lt;port&gt;8080&lt;/port&gt; &lt;path&gt;/&lt;/path&gt; &lt;pactFileDirectory&gt;path/to/pacts&lt;/pactFileDirectory&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Enabling insecure SSL [version 2.2.8+] For providers that are running on SSL with self-signed certificates, you need to enable insecure SSL mode by setting `&lt;insecure&gt;true&lt;/insecure&gt;` on the provider. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;pactFileDirectory&gt;path/to/pacts&lt;/pactFileDirectory&gt; &lt;insecure&gt;true&lt;/insecure&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Specifying a custom trust store [version 2.2.8+] For environments that are running their own certificate chains: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;pactFileDirectory&gt;path/to/pacts&lt;/pactFileDirectory&gt; &lt;trustStore&gt;relative/path/to/trustStore.jks&lt;/trustStore&gt; &lt;trustStorePassword&gt;changeit&lt;/trustStorePassword&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` `trustStore` is either relative to the current working (build) directory. `trustStorePassword` defaults to `changeit`. NOTE: The hostname will still be verified against the certificate. ## Modifying the requests before they are sent Sometimes you may need to add things to the requests that can&apos;t be persisted in a pact file. Examples of these would be authentication tokens, which have a small life span. The Pact Maven plugin provides a request filter that can be set to a Groovy script on the provider that will be called before the request is made. This script will receive the HttpRequest bound to a variable named `request` prior to it being executed. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;requestFilter&gt; // This is a Groovy script that adds an Authorization header to each request request.addHeader(&apos;Authorization&apos;, &apos;oauth-token eyJhbGciOiJSUzI1NiIsIm...&apos;) &lt;/requestFilter&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` __*Important Note:*__ You should only use this feature for things that can not be persisted in the pact file. By modifying the request, you are potentially modifying the contract from the consumer tests! ## Modifying the HTTP Client Used [version 2.2.4+] The default HTTP client is used for all requests to providers (created with a call to `HttpClients.createDefault()`). This can be changed by specifying a closure assigned to createClient on the provider that returns a CloseableHttpClient. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;createClient&gt; // This is a Groovy script that will enable the client to accept self-signed certificates import org.apache.http.ssl.SSLContextBuilder import org.apache.http.conn.ssl.NoopHostnameVerifier import org.apache.http.impl.client.HttpClients HttpClients.custom().setSSLHostnameVerifier(new NoopHostnameVerifier()) .setSslcontext(new SSLContextBuilder().loadTrustMaterial(null, { x509Certificates, s -&gt; true }) .build()) .build() &lt;/createClient&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Turning off URL decoding of the paths in the pact file [version 3.3.3+] By default the paths loaded from the pact file will be decoded before the request is sent to the provider. To turn this behaviour off, set the system property `pact.verifier.disableUrlPathDecoding` to `true`. __*Important Note:*__ If you turn off the url path decoding, you need to ensure that the paths in the pact files are correctly encoded. The verifier will not be able to make a request with an invalid encoded path. ## Plugin Properties The following plugin properties can be specified with `-Dproperty=value` on the command line or in the configuration section: |Property|Description| |--------|-----------| |pact.showStacktrace|This turns on stacktrace printing for each request. It can help with diagnosing network errors| |pact.showFullDiff|This turns on displaying the full diff of the expected versus actual bodies [version 3.3.6+]| |pact.filter.consumers|Comma seperated list of consumer names to verify| |pact.filter.description|Only verify interactions whose description match the provided regular expression| |pact.filter.providerState|Only verify interactions whose provider state match the provided regular expression. An empty string matches interactions that have no state| Example in the configuration section: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;configuration&gt; &lt;pact.showStacktrace&gt;true&lt;/pact.showStacktrace&gt; &lt;/configuration&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Provider States For each provider you can specify a state change URL to use to switch the state of the provider. This URL will receive the providerState description from the pact file before each interaction via a POST. The stateChangeUsesBody controls if the state is passed in the request body or as a query parameter. These values can be set at the provider level, or for a specific consumer. Consumer values take precedent if both are given. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;stateChangeUsesBody&gt;false&lt;/stateChangeUsesBody&gt; &lt;!-- defaults to true --&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChangeForConsumer1&lt;/stateChangeUrl&gt; &lt;stateChangeUsesBody&gt;false&lt;/stateChangeUsesBody&gt; &lt;!-- defaults to true --&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` If the `stateChangeUsesBody` is not specified, or is set to true, then the provider state description will be sent as JSON in the body of the request. If it is set to false, it will passed as a query parameter. As for normal requests (see Modifying the requests before they are sent), a state change request can be modified before it is sent. Set `stateChangeRequestFilter` to a Groovy script on the provider that will be called before the request is made. #### Teardown calls for state changes [version 3.2.5/2.4.7+] You can enable teardown state change calls by setting the property `&lt;stateChangeTeardown&gt;true&lt;/stateChangeTeardown&gt;` on the provider. This will add an `action` parameter to the state change call. The setup call before the test will receive `action=setup`, and then a teardown call will be made afterwards to the state change URL with `action=teardown`. ## Verifying pact files from a pact broker [version 3.1.1+/2.3.1+] You can setup your build to validate against the pacts stored in a pact broker. The pact plugin will query the pact broker for all consumers that have a pact with the provider based on its name. To use it, just configure the `pactBrokerUrl` or `pactBroker` value for the provider with the base URL to the pact broker. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBrokerUrl&gt;http://pact-broker:5000/&lt;/pactBrokerUrl&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### Verifying pacts from an authenticated pact broker [version 3.3.5+] If your pact broker requires authentication (basic authentication is only supported), you can configure the username and password to use by configuring the `authentication` element of the `pactBroker` element of your provider. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBroker&gt; &lt;url&gt;http://pactbroker:1234&lt;/url&gt; &lt;authentication&gt; &lt;username&gt;test&lt;/username&gt; &lt;password&gt;test&lt;/password&gt; &lt;/authentication&gt; &lt;/pactBroker&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### Verifying pacts from an pact broker that match particular tags [version 3.3.5+] If your pacts in your pact broker have been tagged, you can set the tags to fetch by configuring the `tags` element of the `pactBroker` element of your provider. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBroker&gt; &lt;url&gt;http://pactbroker:1234&lt;/url&gt; &lt;tags&gt; &lt;tag&gt;TEST&lt;/tag&gt; &lt;tag&gt;DEV&lt;/tag&gt; &lt;/tags&gt; &lt;/pactBroker&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` This example will fetch and validate the pacts for the TEST and DEV tags. ## Filtering the interactions that are verified You can filter the interactions that are run using three properties: `pact.filter.consumers`, `pact.filter.description` and `pact.filter.providerState`. Adding `-Dpact.filter.consumers=consumer1,consumer2` to the command line or configuration section will only run the pact files for those consumers (consumer1 and consumer2). Adding `-Dpact.filter.description=a request for payment.*` will only run those interactions whose descriptions start with &apos;a request for payment&apos;. `-Dpact.filter.providerState=.*payment` will match any interaction that has a provider state that ends with payment, and `-Dpact.filter.providerState=` will match any interaction that does not have a provider state. # Verifying a message provider [version 2.2.12+] The Maven plugin has been updated to allow invoking test methods that can return the message contents from a message producer. To use it, set the way to invoke the verification to `ANNOTATED_METHOD`. This will allow the pact verification task to scan for test methods that return the message contents. Add something like the following to your maven pom file: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;messageProvider&lt;/name&gt; &lt;verificationType&gt;ANNOTATED_METHOD&lt;/verificationType&gt; &lt;!-- packagesToScan is optional, but leaving it out will result in the entire test classpath being scanned. Set it to the packages where your annotated test method can be found. --&gt; &lt;packagesToScan&gt; &lt;packageToScan&gt;au.com.example.messageprovider.*&lt;/packageToScan&gt; &lt;/packagesToScan&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/messageprovider-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` Now when the pact verify task is run, will look for methods annotated with `@PactVerifyProvider` in the test classpath that have a matching description to what is in the pact file. ```groovy class ConfirmationKafkaMessageBuilderTest { @PactVerifyProvider(&apos;an order confirmation message&apos;) String verifyMessageForOrder() { Order order = new Order() order.setId(10000004) order.setExchange(&apos;ASX&apos;) order.setSecurityCode(&apos;CBA&apos;) order.setPrice(BigDecimal.TEN) order.setUnits(15) order.setGst(new BigDecimal(&apos;15.0&apos;)) odrer.setFees(BigDecimal.TEN) def message = new ConfirmationKafkaMessageBuilder() .withOrder(order) .build() JsonOutput.toJson(message) } } ``` It will then validate that the returned contents matches the contents for the message in the pact file. ## Changing the class path that is scanned By default, the test classpath is scanned for annotated methods. You can override this by setting the `classpathElements` property: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;messageProvider&lt;/name&gt; &lt;verificationType&gt;ANNOTATED_METHOD&lt;/verificationType&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/messageprovider-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;classpathElements&gt; &lt;classpathElement&gt; build/classes/test &lt;/classpathElement&gt; &lt;/classpathElements&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` # Publishing pact files to a pact broker [version 3.2.0+] The pact maven plugin provides a `publish` mojo that can publish all pact files in a directory to a pact broker. To use it, you need to add a publish configuration to the POM that defines the directory where the pact files are and the URL to the pact broker. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.8&lt;/version&gt; &lt;configuration&gt; &lt;pactDirectory&gt;path/to/pact/files&lt;/pactDirectory&gt; &lt;!-- Defaults to ${project.build.directory}/pacts --&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;projectVersion&gt;1.0.100&lt;/projectVersion&gt; &lt;!-- Defaults to ${project.version} --&gt; &lt;trimSnapshot&gt;true&lt;/trimSnapshot&gt; &lt;!-- Defaults to false --&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` You can now execute `mvn pact:publish` to publish the pact files. _NOTE:_ The pact broker requires a version for all published pacts. The `publish` task will use the version of the project by default, but can be overwritten with the `projectVersion` property. Make sure you have set one otherwise the broker will reject the pact files. _NOTE_: By default, the pact broker has issues parsing `SNAPSHOT` versions. You can configure the publisher to automatically remove `-SNAPSHOT` from your version number by setting `trimSnapshot` to true. This setting does not modify non-snapshot versions. ## Publishing to an authenticated pact broker [version 3.3.9+] For an authenticated pact broker, you can pass in the credentials with the `pactBrokerUsername` and `pactBrokerPassword` properties. Currently it only supports basic authentication. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.3.9&lt;/version&gt; &lt;configuration&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;pactBrokerUsername&gt;USERNAME&lt;/pactBrokerUsername&gt; &lt;pactBrokerPassword&gt;PASSWORD&lt;/pactBrokerPassword&gt; &lt;/configuration&gt; &lt;/plugin&gt; ```