Download JAR files tagged by context with all dependencies

This is an open source library for parsing text-based inputs. PARSER makes use of context-free grammars to validate and parse sentences. Having specified such a grammar, the library takes care of parsing text-based inputs and returns a tree of nodes that represents the parsed sentence. Furthermore, it provides ways for interpreting and refining the returned tree of nodes. In essence, the library aims to remove the pain of parsing and instead allow focusing on processing and interpreting parsed results.

SEWOL provides support for the handling of workflow traces. Specifically it allows to specify the shape and content of process traces in terms of entries representing the execution of a specific workflow activity. SEWOL also allows to write these traces on disk as a log file with the help of a special file writer for process logs. Currently it supports plain text, Petrify, MXML and XES log file types. In order to specify security-related context information, SEWOL provides access control models such as access control lists (ACL) and role-based access control models (RBAC). All types of models can be conveniently edited with the help of appropriate dialogs.

The Infinispan Spring Integration project provides Spring integration for Infinispan, a high performance distributed cache. Its primary features are * An implementation of org.springframework.cache.CacheManager, Spring's central caching abstraction, backed by Infinispan's EmbeddedCacheManager. To be used if your Spring-powered application and Infinispan are colocated, i.e. running within the same VM. * An implementation of org.springframework.cache.CacheManager backed by Infinispan's RemoteCacheManager. To bes used if your Spring-powered application accesses Infinispan remotely, i.e. over the network. * An implementation of org.springframework.cache.CacheManager backed by a CacheContainer reference. To be used if your Spring- powered application needs access to a CacheContainer defined outside the application (e.g. retrieved from JNDI) * Spring namespace support allowing shortcut definitions for all the components above In addition, Infinispan Spring Integration offers various FactoryBeans for facilitating creation of Infinispan core classes - Cache, CacheManager, ... - within a Spring context.

This plugin provides integration between Spring and Maven. Plugin goals support loading a Spring context XML file as part of the Maven build lifecycle. The XML file can be on the local file system or be accessible via any URL Spring's resource loading mechanism can understand. Spring's "classpath:context.xml" style notation is supported. Annotated Java classes can also be used to load a Spring context. Maven properties are injected into the Spring context (both XML and annotation style) as a java.util.Properties bean named "mavenProperties". Maven properties are also registered as a top level PropertySource so that Spring's placeholder resolution framework automatically considers them. See Project Reports -> Plugin Documentation for details on plugin goals. By default, the profile "maven" is set as an active Spring profile along with any other active Maven profiles.

MOCCA is the Message-Oriented Command and Context Architecture, providing a GLUE middle-ware that allows sending commands to a peer which are executed by state-less handlers in a specific context. In contrast to the Request-Response scheme the message flow is not fixed by the framework. This allows to implement different communication paradigms (including Request-Response). The whole system can be seen as an automaton with Messages that trigger state transitions in the local Contexts. This library contains the core components, including the GLUE-based implementation.

This library aims to provide a central access point to the services exposed on the ESB without forcing each part of the system to know the actual location of the ESB and the names of the exposed endpoints. For this sake it allows to map service URI (ie referring to service in webLab taxonomy) to the actual exposed URL on the ESB within the context of a specific project. The library and the configuration should be added in portal lib in order to be central and available to any portlets. The mapping is done in a simple spring config file "webLabClient.xml" which must be accessible in JAVA classpath.

Jetty context XML configuration plugin generator helper. This plugin helps you to generate your Context XML file with a dynamic content such as: * classpath entries * web app resources * maven properties Plugin needs a template Jetty context XML file where the dynamic content is injected. Injection of dynamic content is supported as: * altering the DOM with new values * with enabled filtering dynamic values can be replaced as properties (see bellow) Filtering of the template file is supported. Basically it means you can include content from your maven properties in your context XML file. If desired plugin sets two maven properties with the dynamic content: * jetty.conf-plugin.classpath * jetty.conf-plugin.webapp These properties might be used for filtering as well. Plugin resolves project dependency artifacts. These artifacts are transformed into webapp resources and classpath entries. Works with multi-module projects. Works in Eclipse with enabled m2e.

This project is a collection of miscellaneous tools shared by a number of projects of the same author. There are **simple tuples** to use with Java Streams, **type-safe maps** ([inspired by the heterogeneous map pattern](https://www.informit.com/articles/article.aspx?p=2861454&seqNum=8)) described in Effective Java by Joshua Bloch, a **finder** that handles in a smart way queries to data sources, a facility to use the **DCI (Data, Context and Interactions) architectural pattern**, a simple **message bus** suitable for using the pub-sub pattern inside an application, some **test utilities**, an **experimental actor framework** and a few other small things. Yes, the project name is a tribute to the [jazz standard with the same name](https://en.wikipedia.org/wiki/These_Foolish_Things_(Remind_Me_of_You)) by Maschwitz and Strachey.

# Pact Spring/JUnit5 Support This module extends the base [Pact JUnit5 module](../pact-jvm-provider-junit5). See that for more details. For writing Spring 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 `@ExtendWith(SpringExtension.class)` and one of the pact source annotations to your test class (as per a JUnit 5 test), then add a method annotated with `@TestTemplate` and `@ExtendWith(PactVerificationSpringProvider.class)` that takes a `PactVerificationContext` parameter. You will need to call `verifyInteraction()` on the context parameter in your test template method. For example: ```java @ExtendWith(SpringExtension.class) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT) @Provider("Animal Profile Service") @PactBroker public class ContractVerificationTest { @TestTemplate @ExtendWith(PactVerificationSpringProvider.class) void pactVerificationTestTemplate(PactVerificationContext context) { context.verifyInteraction(); } } ``` You will now be able to setup all the required properties using the Spring context, e.g. creating an application YAML file in the test resources: ```yaml pactbroker: host: your.broker.host auth: username: broker-user password: broker.password ``` You can also run pact tests against `MockMvc` without need to spin up the whole application context which takes time and often requires more additional setup (e.g. database). In order to run lightweight tests just use `@WebMvcTest` from Spring and `MockMvcTestTarget` as a test target before each test. For example: ```java @WebMvcTest @Provider("myAwesomeService") @PactBroker class ContractVerificationTest { @Autowired private MockMvc mockMvc; @TestTemplate @ExtendWith(PactVerificationInvocationContextProvider.class) void pactVerificationTestTemplate(PactVerificationContext context) { context.verifyInteraction(); } @BeforeEach void before(PactVerificationContext context) { context.setTarget(new MockMvcTestTarget(mockMvc)); } } ``` You can also use `MockMvcTestTarget` for tests without spring context by providing the controllers manually. For example: ```java @Provider("myAwesomeService") @PactFolder("pacts") class MockMvcTestTargetStandaloneMockMvcTestJava { @TestTemplate @ExtendWith(PactVerificationInvocationContextProvider.class) void pactVerificationTestTemplate(PactVerificationContext context) { context.verifyInteraction(); } @BeforeEach void before(PactVerificationContext context) { MockMvcTestTarget testTarget = new MockMvcTestTarget(); testTarget.setControllers(new DataResource()); context.setTarget(testTarget); } @RestController static class DataResource { @GetMapping("/data") @ResponseStatus(HttpStatus.NO_CONTENT) void getData(@RequestParam("ticketId") String ticketId) { } } } ``` **Important:** Since `@WebMvcTest` starts only Spring MVC components you can't use `PactVerificationSpringProvider` and need to fallback to `PactVerificationInvocationContextProvider`

# 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("myAwesomeService") @PactFolder("pacts") 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("localhost", myProviderPort, "/")); } ``` ## 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'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("X-Auth-Token", "1234"); 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 |