Download JAR files tagged by feature with all dependencies

We have deprecated ZoomVideoSDK maven repository. Since Video SDK features have been modularized, we are deprecating this repository and publishing new releases into the following repositories. See the feature libraries documentation for details. ZoomVideoSDK Core — core Video SDK features: https://mvnrepository.com/artifact/us.zoom.videosdk/zoomvideosdk-core ZoomVideoSDK Annotation — Screen share annotation feature: https://mvnrepository.com/artifact/us.zoom.videosdk/zoomvideosdk-annotation ZoomVideoSDK Videoeffects — Virtual background feature: https://mvnrepository.com/artifact/us.zoom.videosdk/zoomvideosdk-videoeffects The Video SDKs are app development kits provided to enrich apps with video collaboration features to connect customers and communities. Use these SDKs to build apps with highly customized user interfaces along with access to raw video and audio data. Video SDKs are designed to be: * Easy to use: Import libraries, call required functions, and all video conferencing will be handled for you. * Lightweight: Video SDKs are streamlined toolkits with an enormous reduction in size compared to Meeting SDKs with all the power of Zoom's video and audio solutions. * Highly customizable: Raw video and audio data is available to you, allowing your chosen renderer to customize the video experience. Video sessions created by the Video SDKs are launched instantly, bringing a delightful video communication experience to your users with high-quality video and audio. Direct access to raw video and audio data allows improved interaction between users and the app video stream. Imagine a gaming video streaming app with direct interaction between the player and viewers based on in-game events or prompts from the community. Or, imagine an AR streaming platform with direct viewer access to the on-screen video. As with our Meeting SDKs, Video SDKs allow screen-sharing from devices, in-session chat messages, and high-quality video and audio streams similar to Zoom's core capabilities. The Video SDKs enable the following functionality in your app: * Launch a video communication session instantly * Share screen directly from your device * Send instant chat messages during the session * Capture and review raw data locally * Test different rendering schema and enjoy high-quality video and audio streams * Broadcast the video session to third-party live streaming providers To know more, see: https://developers.zoom.us/docs/video-sdk/

Provides the support for <a href="https://tagmycode.com">TagMyCode</a>. This plugin allows you to manage your own snippets.<br/> <br/> Features:<br/> * Add snippets: you can save your code snippets including description, language, and tags<br/> * List snippets (CRUD): snippets are stored locally and you can filter, sort, create, modify, edit or delete them directly from the IDE<br/> * Quick search: you can search your snippets and insert them directly into the document<br/> <br/> CHANGELOG:<br/> <br/> 2.3.0 (released 2020-07-26)<br/> * published plugin into Apache NetBeans Plugin Portal<br/> * filter snippets by languages<br/> <br/> 2.2.1 (released 2018-01-10)<br/> * Quick Search dialog is now resizable</br> * fixed syntax highlight for PHP and HTML</br> * if refresh token is not valid user will be automatically logged out</br> </br> 2.2.0 (released 2017-11-06)<br/> * snippets management works in offline mode<br/> * autodetect language on new snippet<br/> * added settings dialog with editor theme and font size option<br/> * added title and description to snippet view<br/> * changed open browser class<br/> * text can be dragged into table to create a new snippet<br/> * snippets can be dragged directly into editor and the code are copied<br/> * added "save as file" feature<br/> * added "clone snippet" feature<br/> * added "snippet properties" dialog<br/> * detect binary file<br/> <br/> 2.1.0 (released 2017-04-24)<br/> * moved error messages from dialog to Netbeans Notification Log<br/> * added welcome panel<br/> * about dialog shows plugin version and framework version<br/> * moved storage from JSON to SQL<br/> <br/> 2.0 (released 2016-07-11)<br/> * new user interface<br/> * list of snippets stored locally<br/> * syntax highlight powered by <a href="http://bobbylight.github.io/RSyntaxTextArea/">RSyntaxTextArea</a><br/> * snippets are synchronized with server<br/> * filter snippets<br/> * quick search feature<br/> * insert selected snippet at cursor in document<br/> <br/> 1.1.3 (released 2015-12-18)<br/> * Fix for NetBeans 8.1<br/> <br/> 1.1.2 (released 2014-10-03)<br/> * Switched authentication from OAuth 1.0a to OAuth 2<br/> * Console write also snippet title when new snippet is created (thanks to bejoy)<br/> <br/> 1.1 (released 2014-08-19)<br/> * Added "Search snippets" feature<br/> * Fixed some minor bugs<br/> <br/> 1.0 (released 2014-04-14)<br/> * First release with feature "Create snippet"<br/>

HockeySDK-Android implements support for using HockeyApp in your Android application. The following features are currently supported: Collect crash reports:If your app crashes, a crash log is written to the device's storage. If the user starts the app again, they will be asked asked to submit the crash report to HockeyApp. This works for both beta and live apps, i.e. those submitted to Google Play or other app stores. Crash logs contain viable information for you to help resolve the issue. Furthermore, you as a developer can add additional information to the report as well. Update Alpha/Beta apps: The app will check with HockeyApp if a new version for your alpha/beta build is available. If yes, it will show a dialog to users and let them see the release notes, the version history and start the installation process right away. You can even force the installation of certain updates. User Metrics: Understand user behavior to improve your app. Track usage through daily and monthly active users. Monitor crash impacted users. Measure customer engagement through session count. Add custom tracking calls to learn which features your users are actually using. This feature requires a minimum API level of 14 (Android 4.x Ice Cream Sandwich). Feedback: Besides crash reports, collecting feedback from your users from within your app is a great option to help with improving your app. You act on and answer feedback directly from the HockeyApp backend. Authenticate: Identify and authenticate users against your registered testers with the HockeyApp backend.

# Pact Junit 5 Extension ## Overview For writing Pact verification tests with JUnit 5, there is an JUnit 5 Invocation Context Provider that you can use with the `@TestTemplate` annotation. This will generate a test for each interaction found for the pact files for the provider. To use it, add the `@Provider` and one of the pact source annotations to your test class (as per a JUnit 4 test), then add a method annotated with `@TestTemplate` and `@ExtendWith(PactVerificationInvocationContextProvider.class)` that takes a `PactVerificationContext` parameter. You will need to call `verifyInteraction()` on the context parameter in your test template method. For example: ```java @Provider(&quot;myAwesomeService&quot;) @PactFolder(&quot;pacts&quot;) public class ContractVerificationTest { @TestTemplate @ExtendWith(PactVerificationInvocationContextProvider.class) void pactVerificationTestTemplate(PactVerificationContext context) { context.verifyInteraction(); } } ``` For details on the provider and pact source annotations, refer to the [Pact junit runner](../pact-jvm-provider-junit/README.md) docs. ## Test target You can set the test target (the object that defines the target of the test, which should point to your provider) on the `PactVerificationContext`, but you need to do this in a before test method (annotated with `@BeforeEach`). There are three different test targets you can use: `HttpTestTarget`, `HttpsTestTarget` and `AmpqTestTarget`. For example: ```java @BeforeEach void before(PactVerificationContext context) { context.setTarget(HttpTestTarget.fromUrl(new URL(myProviderUrl))); // or something like // context.setTarget(new HttpTestTarget(&quot;localhost&quot;, myProviderPort, &quot;/&quot;)); } ``` ## Provider State Methods Provider State Methods work in the same way as with JUnit 4 tests, refer to the [Pact junit runner](../pact-jvm-provider-junit/README.md) docs. ## Modifying the requests before they are sent **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! 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 Http and Https test targets support injecting the request that will executed into the test template method. You can then add things to the request before calling the `verifyInteraction()` method. For example to add a header: ```java @TestTemplate @ExtendWith(PactVerificationInvocationContextProvider.class) void testTemplate(PactVerificationContext context, HttpRequest request) { // This will add a header to the request request.addHeader(&quot;X-Auth-Token&quot;, &quot;1234&quot;); context.verifyInteraction(); } ``` ## Objects that can be injected into the test methods You can inject the following objects into your test methods (just like the `PactVerificationContext`). They will be null if injected before the supported phase. | Object | Can be injected from phase | Description | | ------ | --------------- | ----------- | | PactVerificationContext | @BeforeEach | The context to use to execute the interaction test | | Pact | any | The Pact model for the test | | Interaction | any | The Interaction model for the test | | HttpRequest | @TestTemplate | The request that is going to be executed (only for HTTP and HTTPS targets) | | ProviderVerifier | @TestTemplate | The verifier instance that is used to verify the interaction |

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.

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`.

Introducing "PerScope" Library: Simplifying Privacy Policy Event Handling for Android Apps "PerScope" is a cutting-edge library designed to streamline the processing of privacy policy events within regions where compliance with local legislation is crucial. Specifically crafted for Android applications, this library addresses the intricate task of managing privacy policy-related events while adhering to the legal requirements of the country in which the app is deployed. In today's digital landscape, ensuring user privacy and data protection is of paramount importance. Different countries have varying legal frameworks dictating how user data should be handled, necessitating robust mechanisms to accommodate these differences seamlessly. This is where the "PerScope" library shines. The key feature that sets "PerScope" apart is its incredible simplicity. With just a single function call, developers can integrate the library into their Android applications and gain immediate access to a comprehensive suite of tools for managing privacy policy events. Whether it's presenting privacy-related notifications, tracking user consents, or adapting the app's behavior based on regional requirements, "PerScope" handles it all efficiently and effectively. Here's a glimpse of what "PerScope" brings to the table: Localized Compliance: "PerScope" empowers developers to align their apps with the privacy laws of each region. By intelligently detecting the user's location, the library ensures that the app's behavior remains compliant with the specific privacy regulations of that area. Event Handling Made Easy: Instead of grappling with complex event management code, developers can integrate the "PerScope" function, drastically reducing development time and effort. The library takes care of the intricate event handling process seamlessly. Dynamic Adaptation: With the ability to dynamically adapt the app's features based on the user's consent and the local legal requirements, "PerScope" ensures a personalized and compliant user experience. Notification Presentation: "PerScope" assists in presenting privacy-related notifications to users, making it easier to inform them about data collection practices and obtain necessary consents. Smooth Integration: The library is designed to be easily integrated into existing Android applications, minimizing disruptions to the development process. In a nutshell, "PerScope" is a developer's go-to solution for managing privacy policy events within Android apps. Its single-function approach, combined with its capacity to handle a complex and critical aspect of app development, makes it an indispensable tool for app creators aiming to provide a user-centric, privacy-respecting experience while complying with regional legislation. Stay on the right side of the law and prioritize user privacy with the power of "PerScope."

Pact provider ============= sub project of https://github.com/DiUS/pact-jvm The pact provider is responsible for verifying that an API provider adheres to a number of pacts authored by its clients This library provides the basic tools required to automate the process, and should be usable on its own in many instances. Framework and build tool specific bindings will be provided in separate libraries that build on top of this core functionality. ### Provider State Before each interaction is executed, the provider under test will have the opportunity to enter a state. Generally the state maps to a set of fixture data for mocking out services that the provider is a consumer of (they will have their own pacts) The pact framework will instruct the test server to enter that state by sending: POST &quot;${config.stateChangeUrl.url}/setup&quot; { &quot;state&quot; : &quot;${interaction.stateName}&quot; } ### An example of running provider verification with junit This example uses Groovy, JUnit 4 and Hamcrest matchers to run the provider verification. As the provider service is a DropWizard application, it uses the DropwizardAppRule to startup the service before running any test. **Warning:** It only grabs the first interaction from the pact file with the consumer, where there could be many. (This could possibly be solved with a parameterized test) ```groovy class ReadmeExamplePactJVMProviderJUnitTest { @ClassRule public static TestRule startServiceRule = new DropwizardAppRule&lt;DropwizardConfiguration&gt;( TestDropwizardApplication.class, ResourceHelpers.resourceFilePath(&quot;dropwizard/test-config.yaml&quot;)) private static ProviderInfo serviceProvider private static Pact&lt;RequestResponseInteraction&gt; testConsumerPact private static ConsumerInfo consumer @BeforeClass static void setupProvider() { serviceProvider = new ProviderInfo(&quot;Dropwizard App&quot;) serviceProvider.setProtocol(&quot;http&quot;) serviceProvider.setHost(&quot;localhost&quot;) serviceProvider.setPort(8080) serviceProvider.setPath(&quot;/&quot;) consumer = new ConsumerInfo() consumer.setName(&quot;test_consumer&quot;) consumer.setPactSource(new UrlSource( ReadmeExamplePactJVMProviderJUnitTest.getResource(&quot;/pacts/zoo_app-animal_service.json&quot;).toString())) testConsumerPact = PactReader.loadPact(consumer.getPactSource()) as Pact&lt;RequestResponseInteraction&gt; } @Test void runConsumerPacts() { // grab the first interaction from the pact with consumer Interaction interaction = testConsumerPact.interactions.get(0) // setup the verifier ProviderVerifier verifier = setupVerifier(interaction, serviceProvider, consumer) // setup any provider state // setup the client and interaction to fire against the provider ProviderClient client = new ProviderClient(serviceProvider, new HttpClientFactory()) Map&lt;String, Object&gt; failures = new HashMap&lt;&gt;() verifier.verifyResponseFromProvider(serviceProvider, interaction, interaction.getDescription(), failures, client) if (!failures.isEmpty()) { verifier.displayFailures(failures) } // Assert all good assertThat(failures, is(empty())) } private ProviderVerifier setupVerifier(Interaction interaction, ProviderInfo provider, ConsumerInfo consumer) { ProviderVerifier verifier = new ProviderVerifier() verifier.initialiseReporters(provider) verifier.reportVerificationForConsumer(consumer, provider) if (!interaction.getProviderStates().isEmpty()) { for (ProviderState providerState: interaction.getProviderStates()) { verifier.reportStateForInteraction(providerState.getName(), provider, consumer, true) } } verifier.reportInteractionDescription(interaction) return verifier } } ``` ### An example of running provider verification with spock This example uses groovy and spock to run the provider verification. Again the provider service is a DropWizard application, and is using the DropwizardAppRule to startup the service. This example runs all interactions using spocks Unroll feature ```groovy class ReadmeExamplePactJVMProviderSpockSpec extends Specification { @ClassRule @Shared TestRule startServiceRule = new DropwizardAppRule&lt;DropwizardConfiguration&gt;(TestDropwizardApplication, ResourceHelpers.resourceFilePath(&apos;dropwizard/test-config.yaml&apos;)) @Shared ProviderInfo serviceProvider ProviderVerifier verifier def setupSpec() { serviceProvider = new ProviderInfo(&apos;Dropwizard App&apos;) serviceProvider.protocol = &apos;http&apos; serviceProvider.host = &apos;localhost&apos; serviceProvider.port = 8080 serviceProvider.path = &apos;/&apos; serviceProvider.hasPactWith(&apos;zoo_app&apos;) { pactSource = new FileSource(new File(ResourceHelpers.resourceFilePath(&apos;pacts/zoo_app-animal_service.json&apos;))) } } def setup() { verifier = new ProviderVerifier() } def cleanup() { // cleanup provider state // ie. db.truncateAllTables() } def cleanupSpec() { // cleanup provider } @Unroll def &quot;Provider Pact - With Consumer #consumer&quot;() { expect: verifyConsumerPact(consumer).empty where: consumer &lt;&lt; serviceProvider.consumers } private Map verifyConsumerPact(ConsumerInfo consumer) { Map failures = [:] verifier.initialiseReporters(serviceProvider) verifier.runVerificationForConsumer(failures, serviceProvider, consumer) if (!failures.empty) { verifier.displayFailures(failures) } failures } } ```

# Pact Junit 5 Extension ## Overview For writing Pact verification tests with JUnit 5, there is an JUnit 5 Invocation Context Provider that you can use with the `@TestTemplate` annotation. This will generate a test for each interaction found for the pact files for the provider. To use it, add the `@Provider` and one of the pact source annotations to your test class (as per a JUnit 4 test), then add a method annotated with `@TestTemplate` and `@ExtendWith(PactVerificationInvocationContextProvider.class)` that takes a `PactVerificationContext` parameter. You will need to call `verifyInteraction()` on the context parameter in your test template method. For example: ```java @Provider(&quot;myAwesomeService&quot;) @PactFolder(&quot;pacts&quot;) public class ContractVerificationTest { @TestTemplate @ExtendWith(PactVerificationInvocationContextProvider.class) void pactVerificationTestTemplate(PactVerificationContext context) { context.verifyInteraction(); } } ``` For details on the provider and pact source annotations, refer to the [Pact junit runner](../pact-jvm-provider-junit/README.md) docs. ## Test target You can set the test target (the object that defines the target of the test, which should point to your provider) on the `PactVerificationContext`, but you need to do this in a before test method (annotated with `@BeforeEach`). There are three different test targets you can use: `HttpTestTarget`, `HttpsTestTarget` and `AmpqTestTarget`. For example: ```java @BeforeEach void before(PactVerificationContext context) { context.setTarget(HttpTestTarget.fromUrl(new URL(myProviderUrl))); // or something like // context.setTarget(new HttpTestTarget(&quot;localhost&quot;, myProviderPort, &quot;/&quot;)); } ``` **Note for Maven users:** If you use Maven to run your tests, you will have to make sure that the Maven Surefire plugin is at least version 2.22.1 uses an isolated classpath. For example, configure it by adding the following to your POM: ```xml &lt;plugin&gt; &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt; &lt;artifactId&gt;maven-surefire-plugin&lt;/artifactId&gt; &lt;version&gt;2.22.1&lt;/version&gt; &lt;configuration&gt; &lt;useSystemClassLoader&gt;false&lt;/useSystemClassLoader&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Provider State Methods Provider State Methods work in the same way as with JUnit 4 tests, refer to the [Pact junit runner](../pact-jvm-provider-junit/README.md) docs. ### Using multiple classes for the state change methods If you have a large number of state change methods, you can split things up by moving them to other classes. You will need to specify the additional classes on the test context in a `Before` method. Do this with the `withStateHandler` or `setStateHandlers` methods. See [StateAnnotationsOnAdditionalClassTest](pact-jvm-provider-junit5/src/test/java/au/com/dius/pact/provider/junit5/StateAnnotationsOnAdditionalClassTest.java) for an example. ## Modifying the requests before they are sent **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! 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 Http and Https test targets support injecting the request that will executed into the test template method. You can then add things to the request before calling the `verifyInteraction()` method. For example to add a header: ```java @TestTemplate @ExtendWith(PactVerificationInvocationContextProvider.class) void testTemplate(PactVerificationContext context, HttpRequest request) { // This will add a header to the request request.addHeader(&quot;X-Auth-Token&quot;, &quot;1234&quot;); context.verifyInteraction(); } ``` ## Objects that can be injected into the test methods You can inject the following objects into your test methods (just like the `PactVerificationContext`). They will be null if injected before the supported phase. | Object | Can be injected from phase | Description | | ------ | --------------- | ----------- | | PactVerificationContext | @BeforeEach | The context to use to execute the interaction test | | Pact | any | The Pact model for the test | | Interaction | any | The Interaction model for the test | | HttpRequest | @TestTemplate | The request that is going to be executed (only for HTTP and HTTPS targets) | | ProviderVerifier | @TestTemplate | The verifier instance that is used to verify the interaction |