Download JAR files tagged by after with all dependencies
excalibur-monitor from group org.apache.excalibur.components (version 2.2.1)
Avalon Excalibur's resource management code allows you to be notified when a resource has changed. There
are two methods of resource management: active and passive. Passive resource management acts as a holder
for resources, and after the resource has been modified through it's normal API, notification goes to all
listeners. Active resource management does the same, but it also polls the resources periodically to see
if the resource was modified through an external method. Active resource management is perfect for
monitoring files because they can be modified by external programs, and your program will be notified when
the change occurs instead of constantly polling it.
0 downloads
Artifact excalibur-monitor
Group org.apache.excalibur.components
Version 2.2.1
Last update 15. February 2007
Organization not specified
URL Not specified
License not specified
Dependencies amount 2
Dependencies avalon-framework-api, excalibur-sourceresolve,
There are maybe transitive dependencies!
Group org.apache.excalibur.components
Version 2.2.1
Last update 15. February 2007
Organization not specified
URL Not specified
License not specified
Dependencies amount 2
Dependencies avalon-framework-api, excalibur-sourceresolve,
There are maybe transitive dependencies!
jcql from group com.trebogeer.jcql (version 0.8.7)
JCQL is a tool allowing to generate boilerplate java code from existing cassandra schema. It is intended to be
used with Cassandra 2.1+ due to support of UDTs (User Defined Types)/Tuples/Collections.
Cassandra's UDTs/Tuples/Collections and an ability to introspect schema through java driver make it possible to
automatically generate POJOs and corresponding mappers between database and java models. Properly generated java
code saves development efforts and is less error-prone compared to hand coding. Accompanied with proper CI and
deployment it can also guarantee consistency between database and java models at any point of application
lifecycle from development to production rollout. JCQL does not rely on java reflection or annotations which
means all discrepancies between actual cassandra schema and what client code expects it to be will be identified
during compilation not at runtime in the middle of the night right after production release. No need to worry
about Cassandra client code performance implications due to use of reflection.
0 downloads
Artifact jcql
Group com.trebogeer.jcql
Version 0.8.7
Last update 11. March 2016
Organization not specified
URL http://github.com/trebogeer/j-cql
License Apache License, Version 2.0
Dependencies amount 10
Dependencies cassandra-all, jaxb-xjc, args4j, snakeyaml, guava, javatuples, slf4j-api, logback-classic, cassandra-driver-core, cassandra-driver-mapping,
There are maybe transitive dependencies!
Group com.trebogeer.jcql
Version 0.8.7
Last update 11. March 2016
Organization not specified
URL http://github.com/trebogeer/j-cql
License Apache License, Version 2.0
Dependencies amount 10
Dependencies cassandra-all, jaxb-xjc, args4j, snakeyaml, guava, javatuples, slf4j-api, logback-classic, cassandra-driver-core, cassandra-driver-mapping,
There are maybe transitive dependencies!
maven-glassfishbuild-extension from group org.glassfish.build (version 3.2.2)
GlassFish build depends on properly functioning several custom lifecycle mappings and
artifact handlers. Because these are necessary to resolve dependencies and to run
"gf:run" goal and etc., it is critical that these extensions be made available to
Maven early on during Maven execution.
This definition was originally in maven-glassfish-plugin, which was integrated
into Maven POM through <plugin>/<extensions>true marking, but after
a series of debugging to resolve artifact resolution failure problems, it turns
out that that doesn't cause Maven to load components early enough.
I tried to circumbent the prolem by also registering the maven-glassfish-plugin
as an extension module (via <build>/<extensions/<extension>), but that
apparently confuses Maven to no end --- I get build errors like this:
[INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-jar-plugin:2.1:jar': Unable to find the mojo 'org.apache.maven.plugins:maven-jar-plugin:2.1:jar' in the plugin 'org.apache.maven.plugins:maven-jar-plugin'
This is obviously one of the problematic areas of Maven, so to avoid doing hack
over hack, I'm simply moving the component definitions to its own module.
Group: org.glassfish.build Artifact: maven-glassfishbuild-extension
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact maven-glassfishbuild-extension
Group org.glassfish.build
Version 3.2.2
Last update 14. September 2011
Organization not specified
URL Not specified
License not specified
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!
Group org.glassfish.build
Version 3.2.2
Last update 14. September 2011
Organization not specified
URL Not specified
License not specified
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!
maven-glassfish-extension from group org.glassfish.build (version 10.0-alpha-4)
GlassFish build depends on properly functioning several custom lifecycle mappings and
artifact handlers. Because these are necessary to resolve dependencies and to run
"gf:run" goal and etc., it is critical that these extensions be made available to
Maven early on during Maven execution.
This definition was originally in maven-glassfish-plugin, which was integrated
into Maven POM through <plugin>/<extensions>true marking, but after
a series of debugging to resolve artifact resolution failure problems, it turns
out that that doesn't cause Maven to load components early enough.
I tried to circumbent the prolem by also registering the maven-glassfish-plugin
as an extension module (via <build>/<extensions/<extension>), but that
apparently confuses Maven to no end --- I get build errors like this:
[INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-jar-plugin:2.1:jar': Unable to find the mojo 'org.apache.maven.plugins:maven-jar-plugin:2.1:jar' in the plugin 'org.apache.maven.plugins:maven-jar-plugin'
This is obviously one of the problematic areas of Maven, so to avoid doing hack
over hack, I'm simply moving the component definitions to its own module.
0 downloads
Artifact maven-glassfish-extension
Group org.glassfish.build
Version 10.0-alpha-4
Last update 30. April 2008
Organization not specified
URL Not specified
License not specified
Dependencies amount 1
Dependencies maven-core,
There are maybe transitive dependencies!
Group org.glassfish.build
Version 10.0-alpha-4
Last update 30. April 2008
Organization not specified
URL Not specified
License not specified
Dependencies amount 1
Dependencies maven-core,
There are maybe transitive dependencies!
gridSearch from group nz.ac.waikato.cms.weka (version 1.0.12)
Performs a grid search of parameter pairs for the a classifier (Y-axis, default is LinearRegression with the "Ridge" parameter) and the PLSFilter (X-axis, "# of Components") and chooses the best pair found for the actual predicting.
The initial grid is worked on with 2-fold CV to determine the values of the parameter pairs for the selected type of evaluation (e.g., accuracy). The best point in the grid is then taken and a 10-fold CV is performed with the adjacent parameter pairs. If a better pair is found, then this will act as new center and another 10-fold CV will be performed (kind of hill-climbing). This process is repeated until no better pair is found or the best pair is on the border of the grid.
In case the best pair is on the border, one can let GridSearch automatically extend the grid and continue the search. Check out the properties 'gridIsExtendable' (option '-extend-grid') and 'maxGridExtensions' (option '-max-grid-extensions <num>').
GridSearch can handle doubles, integers (values are just cast to int) and booleans (0 is false, otherwise true). float, char and long are supported as well.
The best filter/classifier setup can be accessed after the buildClassifier call via the getBestFilter/getBestClassifier methods.
Note on the implementation: after the data has been passed through the filter, a default NumericCleaner filter is applied to the data in order to avoid numbers that are getting too small and might produce NaNs in other schemes.
1 downloads
Artifact gridSearch
Group nz.ac.waikato.cms.weka
Version 1.0.12
Last update 30. October 2018
Organization University of Waikato, Hamilton, NZ
URL http://weka.sourceforge.net/doc.packages/gridSearch
License GNU General Public License 3
Dependencies amount 2
Dependencies weka-dev, partialLeastSquares,
There are maybe transitive dependencies!
Group nz.ac.waikato.cms.weka
Version 1.0.12
Last update 30. October 2018
Organization University of Waikato, Hamilton, NZ
URL http://weka.sourceforge.net/doc.packages/gridSearch
License GNU General Public License 3
Dependencies amount 2
Dependencies weka-dev, partialLeastSquares,
There are maybe transitive dependencies!
rng from group de.cit-ec.ml (version 1.0.0)
This is an implementation of the Neural Gas algorithm on
distance data (Relational Neural Gas) for unsupervised clustering.
We recommend that you use the functions provided by the RelationalNeuralGas
class for your purposes. All other classes and functions are utilities which
are used by this central class. In particular, you can use RelationalNeuralGas.train()
to obtain a RNGModel (i.e. a clustering of your data), and subsequently
you can use RelationalNeuralGas.getAssignments() to obtain the resulting
cluster assignments, and RelationalNeuralGas.classify() to cluster new points
which are not part of the training data set.
The underlying scientific work is summarized nicely in the dissertation
"Topographic Mapping of Dissimilarity Datasets" by Alexander Hasenfuss
(2009).
The basic properties of an Relational Neural Gas algorithm are the following:
1.) It is relational: The data is represented only in terms of a pairwise
distance matrix.
2.) It is a clustering method: The algorithm provides a clustering model,
that is: After calculation,
each data point should be assigned to a cluster (for this package here we
only consider hard clustering, that is: each data point is assigned to
exactly one cluster).
3.) It is a vector quantization method: Each cluster corresponds to a
prototype, which is in the center of the
cluster and data points are assigned to the cluster if and only if they are
closest to this particular prototype.
4.) It is rank-based: The updates of the prototypes depend only on
the distance ranking, not on the absolute value of the distances.
Artifact rng
Group de.cit-ec.ml
Version 1.0.0
Last update 26. January 2018
Organization not specified
URL https://gitlab.ub.uni-bielefeld.de/bpaassen/relational_neural_gas
License The GNU General Public License, Version 3
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!
Group de.cit-ec.ml
Version 1.0.0
Last update 26. January 2018
Organization not specified
URL https://gitlab.ub.uni-bielefeld.de/bpaassen/relational_neural_gas
License The GNU General Public License, Version 3
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!
groupdocs-editor from group com.groupdocs (version 17.9)
GroupDocs.Editor for Java is a powerful document editing API using HTML.
API can be used with any external, opensource or paid HTML editor.
Editor API will process to load documents, convert it to HTML, provide HTML to external UI and then save HTML to original document after manipulation.
It can also be used to generate different PDF files, Microsoft Word (DOC, DOCX), Excel spreadsheets (XLS, XSLSX), PowerPoint presentations (PPT, PPTX) and TXT documents.
Manipulate Using HTML:
Load Document
Edit content using HTML
Edit styles
Perform Editor operations
Convert back to supported file
Document Editor is a computer program for editing HTML, the markup of a webpage.
Although the HTML markup of a web page can be written with any text editor, specialized HTML editors can offer convenience and added functionality.
For example, many HTML editors handle not only HTML, but also related technologies such as CSS, XML and JavaScript or ECMAScript.
In some cases they also manage communication with remote web servers via FTP and WebDAV, and version control systems such as Subversion or Git.
Many word processing, graphic design and page layout programs that are not dedicated to web design, such as Microsoft Word or Quark XPress, also have the ability to function as HTML editors.
Artifact groupdocs-editor
Group com.groupdocs
Version 17.9
Last update 10. January 2018
Organization not specified
URL https://products.groupdocs.com/editor
License GroupDocs License, Version 1.0
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!
Group com.groupdocs
Version 17.9
Last update 10. January 2018
Organization not specified
URL https://products.groupdocs.com/editor
License GroupDocs License, Version 1.0
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!
pact-jvm-provider-lein_2.12 from group au.com.dius (version 3.6.15)
# Leiningen plugin to verify a provider [version 2.2.14+, 3.0.3+]
Leiningen plugin for verifying pacts against a provider. The plugin provides a `pact-verify` task which will verify all
configured pacts against your provider.
## To Use It
### 1. Add the plugin to your project plugins, preferably in it's own profile.
```clojure
:profiles {
:pact {
:plugins [[au.com.dius/pact-jvm-provider-lein_2.11 "3.2.11" :exclusions [commons-logging]]]
:dependencies [[ch.qos.logback/logback-core "1.1.3"]
[ch.qos.logback/logback-classic "1.1.3"]
[org.apache.httpcomponents/httpclient "4.4.1"]]
}}}
```
### 2. Define the pacts between your consumers and providers
You define all the providers and consumers within the `:pact` configuration element of your project.
```clojure
:pact {
:service-providers {
; You can define as many as you need, but each must have a unique name
:provider1 {
; All the provider properties are optional, and have sensible defaults (shown below)
:protocol "http"
:host "localhost"
:port 8080
:path "/"
:has-pact-with {
; Again, you can define as many consumers for each provider as you need, but each must have a unique name
:consumer1 {
; pact file can be either a path or an URL
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
### 3. Execute `lein with-profile pact pact-verify`
You will have to have your provider running for this to pass.
## Enabling insecure SSL
For providers that are running on SSL with self-signed certificates, you need to enable insecure SSL mode by setting
`:insecure true` on the provider.
```clojure
:pact {
:service-providers {
:provider1 {
:protocol "https"
:host "localhost"
:port 8443
:insecure true
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
## Specifying a custom trust store
For environments that are running their own certificate chains:
```clojure
:pact {
:service-providers {
:provider1 {
:protocol "https"
:host "localhost"
:port 8443
:trust-store "relative/path/to/trustStore.jks"
:trust-store-password "changeme"
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
`:trust-store` is relative to the current working (build) directory. `:trust-store-password` 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't be persisted in a pact file. Examples of these would
be authentication tokens, which have a small life span. The Leiningen plugin provides a request filter that can be
set to an anonymous function on the provider that will be called before the request is made. This function will receive the HttpRequest
object as a parameter.
```clojure
:pact {
:service-providers {
:provider1 {
; function that adds an Authorization header to each request
:request-filter #(.addHeader % "Authorization" "oauth-token eyJhbGciOiJSUzI1NiIsIm...")
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
__*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 function assigned to `:create-client` on the provider that returns a `CloseableHttpClient`.
The function will receive the provider info as a parameter.
## 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 options can be specified on the command line:
|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|
|:pact.verifier.publishResults|Publishing of verification results will be skipped unless this property is set to 'true' [version 3.5.18+]|
|:pact.matching.wildcard|Enables matching of map values ignoring the keys when this property is set to 'true'|
Example, to run verification only for a particular consumer:
```
$ lein with-profile pact pact-verify :pact.filter.consumers=:consumer2
```
## 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 `:state-change-uses-body`
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.
```clojure
:pact {
:service-providers {
:provider1 {
:state-change-url "http://localhost:8080/tasks/pactStateChange"
:state-change-uses-body false ; defaults to true
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
If the `:state-change-uses-body` 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 `:state-change-request-filter` to an anonymous function on the provider that will be called before the request is made.
#### Returning values that can be injected (3.6.11+)
You can have values from the provider state callbacks be injected into most places (paths, query parameters, headers,
bodies, etc.). This works by using the V3 spec generators with provider state callbacks that return values. One example
of where this would be useful is API calls that require an ID which would be auto-generated by the database on the
provider side, so there is no way to know what the ID would be beforehand.
There are methods on the consumer DSLs that can provider an expression that contains variables (like '/api/user/${id}'
for the path). The provider state callback can then return a map for values, and the `id` attribute from the map will
be expanded in the expression. For URL callbacks, the values need to be returned as JSON in the response body.
## 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 `:pact.filter.consumers=:consumer1,:consumer2` to the command line will only run the pact files for those
consumers (consumer1 and consumer2). Adding `:pact.filter.description=a request for payment.*` will only run those interactions
whose descriptions start with 'a request for payment'. `:pact.filter.providerState=.*payment` will match any interaction that
has a provider state that ends with payment, and `:pact.filter.providerState=` will match any interaction that does not have a
provider state.
## Starting and shutting down your provider
For the pact verification to run, the provider needs to be running. Leiningen provides a `do` task that can chain tasks
together. So, by creating a `start-app` and `terminate-app` alias, you could so something like:
$ lein with-profile pact do start-app, pact-verify, terminate-app
However, if the pact verification fails the build will abort without running the `terminate-app` task. To have the
start and terminate tasks always run regardless of the state of the verification, you can assign them to `:start-provider-task`
and `:terminate-provider-task` on the provider.
```clojure
:aliases {"start-app" ^{:doc "Starts the app"}
["tasks to start app ..."] ; insert tasks to start the app here
"terminate-app" ^{:doc "Kills the app"}
["tasks to terminate app ..."] ; insert tasks to stop the app here
}
:pact {
:service-providers {
:provider1 {
:start-provider-task "start-app"
:terminate-provider-task "terminate-app"
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
Then you can just run:
$ lein with-profile pact pact-verify
and the `start-app` and `terminate-app` tasks will run before and after the provider verification.
## Specifying the provider hostname at runtime [3.0.4+]
If you need to calculate the provider hostname at runtime (for instance it is run as a new docker container or
AWS instance), you can give an anonymous function as the provider host that returns the host name. The function
will receive the provider information as a parameter.
```clojure
:pact {
:service-providers {
:provider1 {
:host #(calculate-host-name %)
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
Group: au.com.dius Artifact: pact-jvm-provider-lein_2.12
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact pact-jvm-provider-lein_2.12
Group au.com.dius
Version 3.6.15
Last update 29. April 2020
Organization not specified
URL https://github.com/DiUS/pact-jvm
License Apache 2
Dependencies amount 8
Dependencies pact-jvm-provider_2.12, clojure, core.match, leiningen-core, logback-core, logback-classic, httpclient, jansi,
There are maybe transitive dependencies!
Group au.com.dius
Version 3.6.15
Last update 29. April 2020
Organization not specified
URL https://github.com/DiUS/pact-jvm
License Apache 2
Dependencies amount 8
Dependencies pact-jvm-provider_2.12, clojure, core.match, leiningen-core, logback-core, logback-classic, httpclient, jansi,
There are maybe transitive dependencies!
pact-jvm-provider-lein from group au.com.dius (version 4.0.10)
# Leiningen plugin to verify a provider
Leiningen plugin for verifying pacts against a provider. The plugin provides a `pact-verify` task which will verify all
configured pacts against your provider.
## To Use It
### 1. Add the plugin to your project plugins, preferably in it's own profile.
```clojure
:profiles {
:pact {
:plugins [[au.com.dius/pact-jvm-provider-lein "4.0.0" :exclusions [commons-logging]]]
:dependencies [[ch.qos.logback/logback-core "1.1.3"]
[ch.qos.logback/logback-classic "1.1.3"]
[org.apache.httpcomponents/httpclient "4.4.1"]]
}}}
```
### 2. Define the pacts between your consumers and providers
You define all the providers and consumers within the `:pact` configuration element of your project.
```clojure
:pact {
:service-providers {
; You can define as many as you need, but each must have a unique name
:provider1 {
; All the provider properties are optional, and have sensible defaults (shown below)
:protocol "http"
:host "localhost"
:port 8080
:path "/"
:has-pact-with {
; Again, you can define as many consumers for each provider as you need, but each must have a unique name
:consumer1 {
; pact file can be either a path or an URL
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
### 3. Execute `lein with-profile pact pact-verify`
You will have to have your provider running for this to pass.
## Enabling insecure SSL
For providers that are running on SSL with self-signed certificates, you need to enable insecure SSL mode by setting
`:insecure true` on the provider.
```clojure
:pact {
:service-providers {
:provider1 {
:protocol "https"
:host "localhost"
:port 8443
:insecure true
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
## Specifying a custom trust store
For environments that are running their own certificate chains:
```clojure
:pact {
:service-providers {
:provider1 {
:protocol "https"
:host "localhost"
:port 8443
:trust-store "relative/path/to/trustStore.jks"
:trust-store-password "changeme"
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
`:trust-store` is relative to the current working (build) directory. `:trust-store-password` 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't be persisted in a pact file. Examples of these would
be authentication tokens, which have a small life span. The Leiningen plugin provides a request filter that can be
set to an anonymous function on the provider that will be called before the request is made. This function will receive the HttpRequest
object as a parameter.
```clojure
:pact {
:service-providers {
:provider1 {
; function that adds an Authorization header to each request
:request-filter #(.addHeader % "Authorization" "oauth-token eyJhbGciOiJSUzI1NiIsIm...")
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
__*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 function assigned to `:create-client` on the provider that returns a `CloseableHttpClient`.
The function will receive the provider info as a parameter.
## 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 options can be specified on the command line:
|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|
|:pact.verifier.publishResults|Publishing of verification results will be skipped unless this property is set to 'true' [version 3.5.18+]|
|:pact.matching.wildcard|Enables matching of map values ignoring the keys when this property is set to 'true'|
Example, to run verification only for a particular consumer:
```
$ lein with-profile pact pact-verify :pact.filter.consumers=:consumer2
```
## 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 `:state-change-uses-body`
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.
```clojure
:pact {
:service-providers {
:provider1 {
:state-change-url "http://localhost:8080/tasks/pactStateChange"
:state-change-uses-body false ; defaults to true
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
If the `:state-change-uses-body` 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 `:state-change-request-filter` to an anonymous function on the provider that will be called before the request is made.
#### Returning values that can be injected (3.6.11+)
You can have values from the provider state callbacks be injected into most places (paths, query parameters, headers,
bodies, etc.). This works by using the V3 spec generators with provider state callbacks that return values. One example
of where this would be useful is API calls that require an ID which would be auto-generated by the database on the
provider side, so there is no way to know what the ID would be beforehand.
There are methods on the consumer DSLs that can provider an expression that contains variables (like '/api/user/${id}'
for the path). The provider state callback can then return a map for values, and the `id` attribute from the map will
be expanded in the expression. For URL callbacks, the values need to be returned as JSON in the response body.
## 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 `:pact.filter.consumers=:consumer1,:consumer2` to the command line will only run the pact files for those
consumers (consumer1 and consumer2). Adding `:pact.filter.description=a request for payment.*` will only run those interactions
whose descriptions start with 'a request for payment'. `:pact.filter.providerState=.*payment` will match any interaction that
has a provider state that ends with payment, and `:pact.filter.providerState=` will match any interaction that does not have a
provider state.
## Starting and shutting down your provider
For the pact verification to run, the provider needs to be running. Leiningen provides a `do` task that can chain tasks
together. So, by creating a `start-app` and `terminate-app` alias, you could so something like:
$ lein with-profile pact do start-app, pact-verify, terminate-app
However, if the pact verification fails the build will abort without running the `terminate-app` task. To have the
start and terminate tasks always run regardless of the state of the verification, you can assign them to `:start-provider-task`
and `:terminate-provider-task` on the provider.
```clojure
:aliases {"start-app" ^{:doc "Starts the app"}
["tasks to start app ..."] ; insert tasks to start the app here
"terminate-app" ^{:doc "Kills the app"}
["tasks to terminate app ..."] ; insert tasks to stop the app here
}
:pact {
:service-providers {
:provider1 {
:start-provider-task "start-app"
:terminate-provider-task "terminate-app"
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
Then you can just run:
$ lein with-profile pact pact-verify
and the `start-app` and `terminate-app` tasks will run before and after the provider verification.
## Specifying the provider hostname at runtime
If you need to calculate the provider hostname at runtime (for instance it is run as a new docker container or
AWS instance), you can give an anonymous function as the provider host that returns the host name. The function
will receive the provider information as a parameter.
```clojure
:pact {
:service-providers {
:provider1 {
:host #(calculate-host-name %)
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
0 downloads
Artifact pact-jvm-provider-lein
Group au.com.dius
Version 4.0.10
Last update 18. April 2020
Organization not specified
URL https://github.com/DiUS/pact-jvm
License Apache 2
Dependencies amount 10
Dependencies pact-jvm-provider, clojure, core.match, leiningen-core, maven-aether-provider, aether-connector-file, aether-connector-wagon, httpclient, jansi, groovy,
There are maybe transitive dependencies!
Group au.com.dius
Version 4.0.10
Last update 18. April 2020
Organization not specified
URL https://github.com/DiUS/pact-jvm
License Apache 2
Dependencies amount 10
Dependencies pact-jvm-provider, clojure, core.match, leiningen-core, maven-aether-provider, aether-connector-file, aether-connector-wagon, httpclient, jansi, groovy,
There are maybe transitive dependencies!
pact-jvm-provider-lein_2.11 from group au.com.dius (version 3.5.24)
# Leiningen plugin to verify a provider [version 2.2.14+, 3.0.3+]
Leiningen plugin for verifying pacts against a provider. The plugin provides a `pact-verify` task which will verify all
configured pacts against your provider.
## To Use It
### 1. Add the plugin to your project plugins, preferably in it's own profile.
```clojure
:profiles {
:pact {
:plugins [[au.com.dius/pact-jvm-provider-lein_2.11 "3.2.11" :exclusions [commons-logging]]]
:dependencies [[ch.qos.logback/logback-core "1.1.3"]
[ch.qos.logback/logback-classic "1.1.3"]
[org.apache.httpcomponents/httpclient "4.4.1"]]
}}}
```
### 2. Define the pacts between your consumers and providers
You define all the providers and consumers within the `:pact` configuration element of your project.
```clojure
:pact {
:service-providers {
; You can define as many as you need, but each must have a unique name
:provider1 {
; All the provider properties are optional, and have sensible defaults (shown below)
:protocol "http"
:host "localhost"
:port 8080
:path "/"
:has-pact-with {
; Again, you can define as many consumers for each provider as you need, but each must have a unique name
:consumer1 {
; pact file can be either a path or an URL
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
### 3. Execute `lein with-profile pact pact-verify`
You will have to have your provider running for this to pass.
## Enabling insecure SSL
For providers that are running on SSL with self-signed certificates, you need to enable insecure SSL mode by setting
`:insecure true` on the provider.
```clojure
:pact {
:service-providers {
:provider1 {
:protocol "https"
:host "localhost"
:port 8443
:insecure true
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
## Specifying a custom trust store
For environments that are running their own certificate chains:
```clojure
:pact {
:service-providers {
:provider1 {
:protocol "https"
:host "localhost"
:port 8443
:trust-store "relative/path/to/trustStore.jks"
:trust-store-password "changeme"
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
`:trust-store` is relative to the current working (build) directory. `:trust-store-password` 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't be persisted in a pact file. Examples of these would
be authentication tokens, which have a small life span. The Leiningen plugin provides a request filter that can be
set to an anonymous function on the provider that will be called before the request is made. This function will receive the HttpRequest
object as a parameter.
```clojure
:pact {
:service-providers {
:provider1 {
; function that adds an Authorization header to each request
:request-filter #(.addHeader % "Authorization" "oauth-token eyJhbGciOiJSUzI1NiIsIm...")
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
__*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 function assigned to `:create-client` on the provider that returns a `CloseableHttpClient`.
The function will receive the provider info as a parameter.
## 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 options can be specified on the command line:
|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|
|:pact.verifier.publishResults|Publishing of verification results will be skipped unless this property is set to 'true' [version 3.5.18+]|
|:pact.matching.wildcard|Enables matching of map values ignoring the keys when this property is set to 'true'|
Example, to run verification only for a particular consumer:
```
$ lein with-profile pact pact-verify :pact.filter.consumers=consumer2
```
## 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 `:state-change-uses-body`
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.
```clojure
:pact {
:service-providers {
:provider1 {
:state-change-url "http://localhost:8080/tasks/pactStateChange"
:state-change-uses-body false ; defaults to true
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
If the `:state-change-uses-body` 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 `:state-change-request-filter` to an anonymous function on the provider that will be called before the request is made.
## 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 `:pact.filter.consumers=consumer1,consumer2` to the command line will only run the pact files for those
consumers (consumer1 and consumer2). Adding `:pact.filter.description=a request for payment.*` will only run those interactions
whose descriptions start with 'a request for payment'. `:pact.filter.providerState=.*payment` will match any interaction that
has a provider state that ends with payment, and `:pact.filter.providerState=` will match any interaction that does not have a
provider state.
## Starting and shutting down your provider
For the pact verification to run, the provider needs to be running. Leiningen provides a `do` task that can chain tasks
together. So, by creating a `start-app` and `terminate-app` alias, you could so something like:
$ lein with-profile pact do start-app, pact-verify, terminate-app
However, if the pact verification fails the build will abort without running the `terminate-app` task. To have the
start and terminate tasks always run regardless of the state of the verification, you can assign them to `:start-provider-task`
and `:terminate-provider-task` on the provider.
```clojure
:aliases {"start-app" ^{:doc "Starts the app"}
["tasks to start app ..."] ; insert tasks to start the app here
"terminate-app" ^{:doc "Kills the app"}
["tasks to terminate app ..."] ; insert tasks to stop the app here
}
:pact {
:service-providers {
:provider1 {
:start-provider-task "start-app"
:terminate-provider-task "terminate-app"
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
Then you can just run:
$ lein with-profile pact pact-verify
and the `start-app` and `terminate-app` tasks will run before and after the provider verification.
## Specifying the provider hostname at runtime [3.0.4+]
If you need to calculate the provider hostname at runtime (for instance it is run as a new docker container or
AWS instance), you can give an anonymous function as the provider host that returns the host name. The function
will receive the provider information as a parameter.
```clojure
:pact {
:service-providers {
:provider1 {
:host #(calculate-host-name %)
:has-pact-with {
:consumer1 {
:pact-file "path/to/provider1-consumer1-pact.json"
}
}
}
}
}
```
Group: au.com.dius Artifact: pact-jvm-provider-lein_2.11
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact pact-jvm-provider-lein_2.11
Group au.com.dius
Version 3.5.24
Last update 04. November 2018
Organization not specified
URL https://github.com/DiUS/pact-jvm
License Apache 2
Dependencies amount 15
Dependencies kotlin-stdlib-jdk8, kotlin-reflect, slf4j-api, groovy-all, kotlin-logging, scala-library, scala-logging_2.11, pact-jvm-provider_2.11, clojure, core.match, leiningen-core, logback-core, logback-classic, httpclient, jansi,
There are maybe transitive dependencies!
Group au.com.dius
Version 3.5.24
Last update 04. November 2018
Organization not specified
URL https://github.com/DiUS/pact-jvm
License Apache 2
Dependencies amount 15
Dependencies kotlin-stdlib-jdk8, kotlin-reflect, slf4j-api, groovy-all, kotlin-logging, scala-library, scala-logging_2.11, pact-jvm-provider_2.11, clojure, core.match, leiningen-core, logback-core, logback-classic, httpclient, jansi,
There are maybe transitive dependencies!
Page 22 from 24 (items total 236)