Download JAR files tagged by handle with all dependencies
EsiAisParser from group nl.esi.metis (version 0.30)
This package supports the parsing of AIS messages in Java. AIS, the Automatic Identification System, is a system aiming at improving maritime safety by exchanging messages between ships, other vehicles in particular aircraft involved in search-and-rescue (SAR), and (fixed) base stations. To be precise, this package support the ITU-R M.1371-4 AIS standard.
See our extensive javadoc and in particular the class AISParser for more information on how to use this package.
The parser was used in the Poseidon project, and is improved in the Metis project to better handle uncertain information. Both projects were led by the Embedded Systems Institute. In both projects Thales Nederlands was the carrying industrial partner, and multiple Dutch universities participated.
1 downloads
Artifact EsiAisParser
Group nl.esi.metis
Version 0.30
Last update 20. June 2013
Organization not specified
URL http://sourceforge.net/projects/esiaisparser/
License ESI AIS Parser license
Dependencies amount 1
Dependencies colt,
There are maybe transitive dependencies!
Group nl.esi.metis
Version 0.30
Last update 20. June 2013
Organization not specified
URL http://sourceforge.net/projects/esiaisparser/
License ESI AIS Parser license
Dependencies amount 1
Dependencies colt,
There are maybe transitive dependencies!
stepping from group com.imperva.stepping (version 5.1.0)
Stepping is a framework designed to ease the implementation of data processing solutions.
In use cases where we need to implement data or data-streaming algorithms or any other processing on data, we need to
first handle many different infrastructure issues.
For example, we need to decide how to split the data processing logic into different steps, think about our threading policy,
how to handle communication between the different steps, error handling etc.
One of the most important subjects is the Threading Policy of our solution. For example, we need to think how many threads
to open, have the option to distribute the processing of data to multiple 'executors' in parallel, have a thread-safe
communication layer between the threads etc.
On top of that we also care a lot about the performance of our solution, we want to make sure that the latency added by
these infrastructures is minimal as possible.
Stepping aims to handle many of these aspects so developers can spend their time on the business logic instead of
solving these infrastructure and data flow issues issues over and over again.
0 downloads
Artifact stepping
Group com.imperva.stepping
Version 5.1.0
Last update 01. July 2024
Organization not specified
URL https://github.com/imperva/stepping.git
License The Apache License, Version 2.0
Dependencies amount 6
Dependencies slf4j-simple, perf-sampler, slf4j-api, gs-core, gs-ui-swing, spring-context,
There are maybe transitive dependencies!
Group com.imperva.stepping
Version 5.1.0
Last update 01. July 2024
Organization not specified
URL https://github.com/imperva/stepping.git
License The Apache License, Version 2.0
Dependencies amount 6
Dependencies slf4j-simple, perf-sampler, slf4j-api, gs-core, gs-ui-swing, spring-context,
There are maybe transitive dependencies!
rush from group edu.utah.bmi.nlp (version 3.0)
RuSH is an efficient, reliable, and easy adaptable rule-based sentence segmentation solution. It is
specifically designed to handle the telegraphic written text in clinical note. It leverages a nested hash table
to execute simultaneous rule processing, which reduces the impact of the rule-base growth on execution time and
eliminates the effect of rule order on accuracy.
If you wish to cite RuSH in a publication, please use:
Jianlin Shi ; Danielle Mowery ; Kristina M. Doing-Harris ; John F. Hurdle.RuSH: a Rule-based Segmentation Tool
Using Hashing for Extremely Accurate Sentence Segmentation of Clinical Text. AMIA Annu Symp Proc. 2016: 1587.
The full text can be found at:
https://knowledge.amia.org/amia-63300-1.3360278/t005-1.3362920/f005-1.3362921/2495498-1.3363244/2495498-1.3363247?timeStamp=1479743941616
This version allows defining section scopes for sentence segmentation.
Artifact rush
Group edu.utah.bmi.nlp
Version 3.0
Last update 10. February 2018
Organization The Department of Biomedical Informatics, University of Utah
URL https://github.com/jianlins/RuSH
License The Apache Software License, Version 2
Dependencies amount 3
Dependencies nlp-core, fastner, junit-repeat-rule,
There are maybe transitive dependencies!
Group edu.utah.bmi.nlp
Version 3.0
Last update 10. February 2018
Organization The Department of Biomedical Informatics, University of Utah
URL https://github.com/jianlins/RuSH
License The Apache Software License, Version 2
Dependencies amount 3
Dependencies nlp-core, fastner, junit-repeat-rule,
There are maybe transitive dependencies!
rush from group edu.utah.bmi (version 1.0)
RuSH is an efficient, reliable, and easy adaptable rule-based sentence segmentation solution. It is
specifically designed to handle the telegraphic written text in clinical note. It leverages a nested hash table
to execute simultaneous rule processing, which reduces the impact of the rule-base growth on execution time and
eliminates the effect of rule order on accuracy.
If you wish to cite RuSH in a publication, please use:
Jianlin Shi ; Danielle Mowery ; Kristina M. Doing-Harris ; John F. Hurdle.RuSH: a Rule-based Segmentation Tool
Using Hashing for Extremely Accurate Sentence Segmentation of Clinical Text. AMIA Annu Symp Proc. 2016: 1587.
The full text can be found at:
https://knowledge.amia.org/amia-63300-1.3360278/t005-1.3362920/f005-1.3362921/2495498-1.3363244/2495498-1.3363247?timeStamp=1479743941616
Artifact rush
Group edu.utah.bmi
Version 1.0
Last update 23. April 2017
Organization The Department of Biomedical Informatics, University of Utah
URL https://github.com/jianlins/RuSH
License The Apache Software License, Version 2
Dependencies amount 6
Dependencies uimaj-core, uimaj-tools, uimaj-document-annotation, uimafit-core, uimaj-examples, junit,
There are maybe transitive dependencies!
Group edu.utah.bmi
Version 1.0
Last update 23. April 2017
Organization The Department of Biomedical Informatics, University of Utah
URL https://github.com/jianlins/RuSH
License The Apache Software License, Version 2
Dependencies amount 6
Dependencies uimaj-core, uimaj-tools, uimaj-document-annotation, uimafit-core, uimaj-examples, junit,
There are maybe transitive dependencies!
paceRegression from group nz.ac.waikato.cms.weka (version 1.0.2)
Class for building pace regression linear models and using them for prediction.
Under regularity conditions, pace regression is provably optimal when the number of coefficients tends to infinity. It consists of a group of estimators that are either overall optimal or optimal under certain conditions.
The current work of the pace regression theory, and therefore also this implementation, do not handle:
- missing values
- non-binary nominal attributes
- the case that n - k is small where n is the number of instances and k is the number of coefficients (the threshold used in this implmentation is 20)
For more information see:
Wang, Y (2000). A new approach to fitting linear models in high dimensional spaces. Hamilton, New Zealand.
Wang, Y., Witten, I. H.: Modeling for optimal probability prediction. In: Proceedings of the Nineteenth International Conference in Machine Learning, Sydney, Australia, 650-657, 2002.
Group: nz.ac.waikato.cms.weka Artifact: paceRegression
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact paceRegression
Group nz.ac.waikato.cms.weka
Version 1.0.2
Last update 26. April 2012
Organization University of Waikato, Hamilton, NZ
URL http://weka.sourceforge.net/doc.packages/paceRegression
License GNU General Public License 3
Dependencies amount 1
Dependencies weka-dev,
There are maybe transitive dependencies!
Group nz.ac.waikato.cms.weka
Version 1.0.2
Last update 26. April 2012
Organization University of Waikato, Hamilton, NZ
URL http://weka.sourceforge.net/doc.packages/paceRegression
License GNU General Public License 3
Dependencies amount 1
Dependencies weka-dev,
There are maybe transitive dependencies!
spring-ldap from group org.springframework.ldap (version 1.3.1.RELEASE)
Spring LDAP is a Java library for simplifying LDAP
operations, based on the pattern of Spring's JdbcTemplate. The
framework relieves the user of common chores, such as looking up and
closing contexts, looping through results, encoding/decoding values
and filters, and more. The LdapTemplate class encapsulates all the
plumbing work involved in traditional LDAP programming, such as
creating a DirContext, looping through NamingEnumerations, handling
exceptions and cleaning up resources. This leaves the programmer to
handle the important stuff - where to find data (DNs and Filters) and
what do do with it (map to and from domain objects, bind, modify,
unbind, etc.), in the same way that JdbcTemplate relieves the
programmer of all but the actual SQL and how the data maps to the
domain model. In addition to this, Spring LDAP provides transaction
support, a pooling library, exception translation from
NamingExceptions to a mirrored unchecked Exception hierarchy, as well
as several utilities for working with filters, LDAP paths and
Attributes.
Group: org.springframework.ldap Artifact: spring-ldap
Show all versions
Show all versions
There is no JAR file uploaded. A download is not possible! Please choose another version.
6 downloads
Artifact spring-ldap
Group org.springframework.ldap
Version 1.3.1.RELEASE
Last update 01. December 2010
Organization The Spring LDAP Framework
URL http://springframework.org/ldap
License The Apache Software License, Version 2.0
Dependencies amount 1
Dependencies spring-core,
There are maybe transitive dependencies!
Group org.springframework.ldap
Version 1.3.1.RELEASE
Last update 01. December 2010
Organization The Spring LDAP Framework
URL http://springframework.org/ldap
License The Apache Software License, Version 2.0
Dependencies amount 1
Dependencies spring-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!
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!
PerScope from group io.github.danielandroidtt (version 1.4.0)
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."
Group: io.github.danielandroidtt Artifact: PerScope
Show all versions
Show all versions
There is no JAR file uploaded. A download is not possible! Please choose another version.
0 downloads
Artifact PerScope
Group io.github.danielandroidtt
Version 1.4.0
Last update 27. August 2023
Organization not specified
URL https://github.com/DanielAndroidTT/PerScope
License MIT License
Dependencies amount 1
Dependencies kotlin-stdlib-jdk8,
There are maybe transitive dependencies!
Group io.github.danielandroidtt
Version 1.4.0
Last update 27. August 2023
Organization not specified
URL https://github.com/DanielAndroidTT/PerScope
License MIT License
Dependencies amount 1
Dependencies kotlin-stdlib-jdk8,
There are maybe transitive dependencies!
pact-jvm-consumer-groovy_2.12 from group au.com.dius (version 3.6.15)
pact-jvm-consumer-groovy
=========================
Groovy DSL for Pact JVM
## Dependency
The library is available on maven central using:
* group-id = `au.com.dius`
* artifact-id = `pact-jvm-consumer-groovy_2.11`
* version-id = `3.5.x`
## Usage
Add the `pact-jvm-consumer-groovy` library to your test class path. This provides a `PactBuilder` class for you to use
to define your pacts. For a full example, have a look at the example JUnit `ExampleGroovyConsumerPactTest`.
If you are using gradle for your build, add it to your `build.gradle`:
dependencies {
testCompile 'au.com.dius:pact-jvm-consumer-groovy_2.11:3.5.0'
}
Then create an instance of the `PactBuilder` in your test.
```groovy
import au.com.dius.pact.consumer.PactVerificationResult
import au.com.dius.pact.consumer.groovy.PactBuilder
import groovyx.net.http.RESTClient
import org.junit.Test
class AliceServiceConsumerPactTest {
@Test
void "A service consumer side of a pact goes a little something like this"() {
def alice_service = new PactBuilder() // Create a new PactBuilder
alice_service {
serviceConsumer "Consumer" // Define the service consumer by name
hasPactWith "Alice Service" // Define the service provider that it has a pact with
port 1234 // The port number for the service. It is optional, leave it out to
// to use a random one
given('there is some good mallory') // defines a provider state. It is optional.
uponReceiving('a retrieve Mallory request') // upon_receiving starts a new interaction
withAttributes(method: 'get', path: '/mallory') // define the request, a GET request to '/mallory'
willRespondWith( // define the response we want returned
status: 200,
headers: ['Content-Type': 'text/html'],
body: '"That is some good Mallory."'
)
}
// Execute the run method to have the mock server run.
// It takes a closure to execute your requests and returns a PactVerificationResult.
PactVerificationResult result = alice_service.runTest {
def client = new RESTClient('http://localhost:1234/')
def alice_response = client.get(path: '/mallory')
assert alice_response.status == 200
assert alice_response.contentType == 'text/html'
def data = alice_response.data.text()
assert data == '"That is some good Mallory."'
}
assert result == PactVerificationResult.Ok.INSTANCE // This means it is all good
}
}
```
After running this test, the following pact file is produced:
{
"provider" : {
"name" : "Alice Service"
},
"consumer" : {
"name" : "Consumer"
},
"interactions" : [ {
"provider_state" : "there is some good mallory",
"description" : "a retrieve Mallory request",
"request" : {
"method" : "get",
"path" : "/mallory",
"requestMatchers" : { }
},
"response" : {
"status" : 200,
"headers" : {
"Content-Type" : "text/html"
},
"body" : "That is some good Mallory.",
"responseMatchers" : { }
}
} ]
}
### DSL Methods
#### serviceConsumer(String consumer)
This names the service consumer for the pact.
#### hasPactWith(String provider)
This names the service provider for the pact.
#### port(int port)
Sets the port that the mock server will run on. If not supplied, a random port will be used.
#### given(String providerState)
Defines a state that the provider needs to be in for the request to succeed. For more info, see
https://github.com/realestate-com-au/pact/wiki/Provider-states. Can be called multiple times.
#### given(String providerState, Map params)
Defines a state that the provider needs to be in for the request to succeed. For more info, see
https://github.com/realestate-com-au/pact/wiki/Provider-states. Can be called multiple times, and the params
map can contain the data required for the state.
#### uponReceiving(String requestDescription)
Starts the definition of a of a pact interaction.
#### withAttributes(Map requestData)
Defines the request for the interaction. The request data map can contain the following:
| key | Description | Default Value |
|----------------------------|-------------------------------------------|-----------------------------|
| method | The HTTP method to use | get |
| path | The Path for the request | / |
| query | Query parameters as a Map<String, List> | |
| headers | Map of key-value pairs for the request headers | |
| body | The body of the request. If it is not a string, it will be converted to JSON. Also accepts a PactBodyBuilder. | |
| prettyPrint | Boolean value to control if the body is pretty printed. See note on Pretty Printed Bodies below |
For the path, header attributes and query parameters (version 2.2.2+ for headers, 3.3.7+ for query parameters),
you can use regular expressions to match. You can either provide a regex `Pattern` class or use the `regexp` method
to construct a `RegexpMatcher` (you can use any of the defined matcher methods, see DSL methods below).
If you use a `Pattern`, or the `regexp` method but don't provide a value, a random one will be generated from the
regular expression. This value is used when generating requests.
For example:
```groovy
.withAttributes(path: ~'/transaction/[0-9]+') // This will generate a random path for requests
// or
.withAttributes(path: regexp('/transaction/[0-9]+', '/transaction/1234567890'))
```
#### withBody(Closure closure)
Constructs the body of the request or response by invoking the supplied closure in the context of a PactBodyBuilder.
##### Pretty Printed Bodies [Version 2.2.15+, 3.0.4+]
An optional Map can be supplied to control how the body is generated. The option values are available:
| Option | Description |
|--------|-------------|
| mimeType | The mime type of the body. Defaults to `application/json` |
| prettyPrint | Boolean value controlling whether to pretty-print the body or not. Defaults to true |
If the prettyPrint option is not specified, the bodies will be pretty printed unless the mime type corresponds to one
that requires compact bodies. Currently only `application/x-thrift+json` is classed as requiring a compact body.
For an example of turning off pretty printing:
```groovy
service {
uponReceiving('a request')
withAttributes(method: 'get', path: '/')
withBody(prettyPrint: false) {
name 'harry'
surname 'larry'
}
}
```
#### willRespondWith(Map responseData)
Defines the response for the interaction. The response data map can contain the following:
| key | Description | Default Value |
|----------------------------|-------------------------------------------|-----------------------------|
| status | The HTTP status code to return | 200 |
| headers | Map of key-value pairs for the response headers | |
| body | The body of the response. If it is not a string, it will be converted to JSON. Also accepts a PactBodyBuilder. | |
| prettyPrint | Boolean value to control if the body is pretty printed. See note on Pretty Printed Bodies above |
For the headers (version 2.2.2+), you can use regular expressions to match. You can either provide a regex `Pattern` class or use
the `regexp` method to construct a `RegexpMatcher` (you can use any of the defined matcher methods, see DSL methods below).
If you use a `Pattern`, or the `regexp` method but don't provide a value, a random one will be generated from the
regular expression. This value is used when generating responses.
For example:
```groovy
.willRespondWith(headers: [LOCATION: ~'/transaction/[0-9]+']) // This will generate a random location value
// or
.willRespondWith(headers: [LOCATION: regexp('/transaction/[0-9]+', '/transaction/1234567890')])
```
#### PactVerificationResult runTest(Closure closure)
The `runTest` method starts the mock server, and then executes the provided closure. It then returns the pact verification
result for the pact run. If you require access to the mock server configuration for the URL, it is passed into the
closure, e.g.,
```groovy
PactVerificationResult result = alice_service.runTest() { mockServer ->
def client = new RESTClient(mockServer.url)
def alice_response = client.get(path: '/mallory')
}
```
### Note on HTTP clients and persistent connections
Some HTTP clients may keep the connection open, based on the live connections settings or if they use a connection cache. This could
cause your tests to fail if the client you are testing lives longer than an individual test, as the mock server will be started
and shutdown for each test. This will result in the HTTP client connection cache having invalid connections. For an example of this where
the there was a failure for every second test, see [Issue #342](https://github.com/DiUS/pact-jvm/issues/342).
### Body DSL
For building JSON bodies there is a `PactBodyBuilder` that provides as DSL that includes matching with regular expressions
and by types. For a more complete example look at `PactBodyBuilderTest`.
For an example:
```groovy
service {
uponReceiving('a request')
withAttributes(method: 'get', path: '/')
withBody {
name(~/\w+/, 'harry')
surname regexp(~/\w+/, 'larry')
position regexp(~/staff|contractor/, 'staff')
happy(true)
}
}
```
This will return the following body:
```json
{
"name": "harry",
"surname": "larry",
"position": "staff",
"happy": true
}
```
and add the following matchers:
```json
{
"$.body.name": {"regex": "\\w+"},
"$.body.surname": {"regex": "\\w+"},
"$.body.position": {"regex": "staff|contractor"}
}
```
#### DSL Methods
The DSL supports the following matching methods:
* regexp(Pattern re, String value = null), regexp(String regexp, String value = null)
Defines a regular expression matcher. If the value is not provided, a random one will be generated.
* hexValue(String value = null)
Defines a matcher that accepts hexidecimal values. If the value is not provided, a random hexidcimal value will be
generated.
* identifier(def value = null)
Defines a matcher that accepts integer values. If the value is not provided, a random value will be generated.
* ipAddress(String value = null)
Defines a matcher that accepts IP addresses. If the value is not provided, a 127.0.0.1 will be used.
* numeric(Number value = null)
Defines a matcher that accepts any numerical values. If the value is not provided, a random integer will be used.
* integer(def value = null)
Defines a matcher that accepts any integer values. If the value is not provided, a random integer will be used.
* decimal(def value = null)
Defines a matcher that accepts any decimal numbers. If the value is not provided, a random decimal will be used.
* timestamp(String pattern = null, def value = null)
If pattern is not provided the ISO_DATETIME_FORMAT is used ("yyyy-MM-dd'T'HH:mm:ss") . If the value is not provided, the current date and time is used.
* time(String pattern = null, def value = null)
If pattern is not provided the ISO_TIME_FORMAT is used ("'T'HH:mm:ss") . If the value is not provided, the current date and time is used.
* date(String pattern = null, def value = null)
If pattern is not provided the ISO_DATE_FORMAT is used ("yyyy-MM-dd") . If the value is not provided, the current date and time is used.
* uuid(String value = null)
Defines a matcher that accepts UUIDs. A random one will be generated if no value is provided.
* equalTo(def value)
Defines an equality matcher that always matches the provided value using `equals`. This is useful for resetting cascading
type matchers.
* includesStr(def value)
Defines a matcher that accepts any value where its string form includes the provided string.
* nullValue()
Defines a matcher that accepts only null values.
* url(String basePath, Object... pathFragments)
Defines a matcher for URLs, given the base URL path and a sequence of path fragments. The path fragments could be
strings or regular expression matchers. For example:
```groovy
url('http://localhost:8080', 'pacticipants', regexp('[^\\/]+', 'Activity%20Service'))
```
Defines a matcher that accepts only null values.
#### What if a field matches a matcher name in the DSL?
When using the body DSL, if there is a field that matches a matcher name (e.g. a field named 'date') then you can do the following:
```groovy
withBody {
date = date()
}
```
### Ensuring all items in a list match an example (2.2.0+)
Lots of the time you might not know the number of items that will be in a list, but you want to ensure that the list
has a minimum or maximum size and that each item in the list matches a given example. You can do this with the `eachLike`,
`minLike` and `maxLike` functions.
| function | description |
|----------|-------------|
| `eachLike()` | Ensure that each item in the list matches the provided example |
| `maxLike(integer max)` | Ensure that each item in the list matches the provided example and the list is no bigger than the provided max |
| `minLike(integer min)` | Ensure that each item in the list matches the provided example and the list is no smaller than the provided min |
For example:
```groovy
withBody {
users minLike(1) {
id identifier
name string('Fred')
}
}
```
This will ensure that the user list is never empty and that each user has an identifier that is a number and a name that is a string.
__Version 3.2.4/2.4.6+__ You can specify the number of example items to generate in the array. The default is 1.
```groovy
withBody {
users minLike(1, 3) {
id identifier
name string('Fred')
}
}
```
This will create an example user list with 3 users.
__Version 3.2.13/2.4.14+__ The each like matchers have been updated to work with primitive types.
```groovy
withBody {
permissions eachLike(3, 'GRANT')
}
```
will generate the following JSON
```json
{
"permissions": ["GRANT", "GRANT", "GRANT"]
}
```
and matchers
```json
{
"$.body.permissions": {"match": "type"}
}
```
and now you can even get more fancy
```groovy
withBody {
permissions eachLike(3, regexp(~/\w+/))
permissions2 minLike(2, 3, integer())
permissions3 maxLike(4, 3, ~/\d+/)
}
```
You can also match arrays at the root level, for instance,
```groovy
withBody PactBodyBuilder.eachLike(regexp(~/\w+/))
```
or if you have arrays of arrays
```groovy
withBody PactBodyBuilder.eachLike([ regexp('[0-9a-f]{8}', 'e8cda07e'), regexp(~/\w+/, 'sony') ])
```
__Version 3.5.9+__ A `eachArrayLike` method has been added to handle matching of arrays of arrays.
```groovy
{
answers minLike(1) {
questionId string("books")
answer eachArrayLike {
questionId string("title")
answer string("BBBB")
}
}
```
This will generate an array of arrays for the `answer` attribute.
### Matching any key in a map (3.3.1/2.5.0+)
The DSL has been extended for cases where the keys in a map are IDs. For an example of this, see
[#313](https://github.com/DiUS/pact-jvm/issues/313). In this case you can use the `keyLike` method, which takes an
example key as a parameter.
For example:
```groovy
withBody {
example {
one {
keyLike '001', 'value' // key like an id mapped to a value
}
two {
keyLike 'ABC001', regexp('\\w+') // key like an id mapped to a matcher
}
three {
keyLike 'XYZ001', { // key like an id mapped to a closure
id identifier()
}
}
four {
keyLike '001XYZ', eachLike { // key like an id mapped to an array where each item is matched by the following
id identifier() // example
}
}
}
}
```
For an example, have a look at [WildcardPactSpec](src/test/au/com/dius/pact/consumer/groovy/WildcardPactSpec.groovy).
**NOTE:** The `keyLike` method adds a `*` to the matching path, so the matching definition will be applied to all keys
of the map if there is not a more specific matcher defined for a particular key. Having more than one `keyLike` condition
applied to a map will result in only one being applied when the pact is verified (probably the last).
**Further Note: From version 3.5.22 onwards pacts with wildcards applied to map keys will require the Java system property
"pact.matching.wildcard" set to value "true" when the pact file is verified.**
### Matching with an OR (3.5.0+)
The V3 spec allows multiple matchers to be combined using either AND or OR for a value. The main use of this would be to
either be able to match a value or a null, or to combine different matchers.
For example:
```groovy
withBody {
valueA and('AB', includeStr('A'), includeStr('B')) // valueA must include both A and B
valueB or('100', regex(~/\d+/), nullValue()) // valueB must either match a regular expression or be null
valueC or('12345678', regex(~/\d{8}/), regex(~/X\d{13}/)) // valueC must match either 8 or X followed by 13 digits
}
```
## Changing the directory pact files are written to (2.1.9+)
By default, pact files are written to `target/pacts` (or `build/pacts` if you use Gradle), but this can be overwritten with the `pact.rootDir` system property.
This property needs to be set on the test JVM as most build tools will fork a new JVM to run the tests.
For Gradle, add this to your build.gradle:
```groovy
test {
systemProperties['pact.rootDir'] = "$buildDir/custom-pacts-directory"
}
```
## Forcing pact files to be overwritten (3.6.5+)
By default, when the pact file is written, it will be merged with any existing pact file. To force the file to be
overwritten, set the Java system property `pact.writer.overwrite` to `true`.
# Publishing your pact files to a pact broker
If you use Gradle, you can use the [pact Gradle plugin](https://github.com/DiUS/pact-jvm/tree/master/provider/pact-jvm-provider-gradle#publishing-pact-files-to-a-pact-broker) to publish your pact files.
# Pact Specification V3
Version 3 of the pact specification changes the format of pact files in the following ways:
* Query parameters are stored in a map form and are un-encoded (see [#66](https://github.com/DiUS/pact-jvm/issues/66)
and [#97](https://github.com/DiUS/pact-jvm/issues/97) for information on what this can cause).
* Introduces a new message pact format for testing interactions via a message queue.
* Multiple provider states can be defined with data parameters.
## Generating V3 spec pact files (3.1.0+, 2.3.0+)
To have your consumer tests generate V3 format pacts, you can pass an option into the `runTest` method. For example:
```groovy
PactVerificationResult result = service.runTest(specificationVersion: PactSpecVersion.V3) { config ->
def client = new RESTClient(config.url)
def response = client.get(path: '/')
}
```
## Consumer test for a message consumer
For testing a consumer of messages from a message queue, the `PactMessageBuilder` class provides a DSL for defining
your message expectations. It works in much the same way as the `PactBuilder` class for Request-Response interactions,
but will generate a V3 format message pact file.
The following steps demonstrate how to use it.
### Step 1 - define the message expectations
Create a test that uses the `PactMessageBuilder` to define a message expectation, and then call `run`. This will invoke
the given closure with a message for each one defined in the pact.
```groovy
def eventStream = new PactMessageBuilder().call {
serviceConsumer 'messageConsumer'
hasPactWith 'messageProducer'
given 'order with id 10000004 exists'
expectsToReceive 'an order confirmation message'
withMetaData(type: 'OrderConfirmed') // Can define any key-value pairs here
withContent(contentType: 'application/json') {
type 'OrderConfirmed'
audit {
userCode 'messageService'
}
origin 'message-service'
referenceId '10000004-2'
timeSent: '2015-07-22T10:14:28+00:00'
value {
orderId '10000004'
value '10.000000'
fee '10.00'
gst '15.00'
}
}
}
```
### Step 2 - call your message handler with the generated messages
This example tests a message handler that gets messages from a Kafka topic. In this case the Pact message is wrapped
as a Kafka `MessageAndMetadata`.
```groovy
eventStream.run { Message message ->
messageHandler.handleMessage(new MessageAndMetadata('topic', 1,
new kafka.message.Message(message.contentsAsBytes()), 0, null, valueDecoder))
}
```
### Step 3 - validate that the message was handled correctly
```groovy
def order = orderRepository.getOrder('10000004')
assert order.status == 'confirmed'
assert order.value == 10.0
```
### Step 4 - Publish the pact file
If the test was successful, a pact file would have been produced with the message from step 1.
# Having values injected from provider state callbacks (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.
The DSL method `fromProviderState` allows you to set an expression that will be parsed with the values returned from the provider states.
For the body, you can use the key value instead of an expression.
For example, assume that an API call is made to get the details of a user by ID. A provider state can be defined that
specifies that the user must be exist, but the ID will be created when the user is created. So we can then define an
expression for the path where the ID will be replaced with the value returned from the provider state callback.
```groovy
service {
given('User harry exists')
uponReceiving('a request for user harry')
withAttributes(method: 'get', path: fromProviderState('/api/user/${id}', '/api/user/100'))
withBody {
name(fromProviderState('userName', 'harry')) // looks up the value using the userName key
}
}
```
Group: au.com.dius Artifact: pact-jvm-consumer-groovy_2.12
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact pact-jvm-consumer-groovy_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 1
Dependencies pact-jvm-consumer_2.12,
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 1
Dependencies pact-jvm-consumer_2.12,
There are maybe transitive dependencies!
Page 90 from 3 (items total 902)