Download JAR files tagged by setting with all dependencies

An implementation of the Ordinal Stochastic Dominance Learner. Further information regarding the OSDL-algorithm can be found in: S. Lievens, B. De Baets, K. Cao-Van (2006). A Probabilistic Framework for the Design of Instance-Based Supervised Ranking Algorithms in an Ordinal Setting. Annals of Operations Research; Kim Cao-Van (2003). Supervised ranking: from semantics to algorithms; Stijn Lievens (2004). Studie en implementatie van instantie-gebaseerde algoritmen voor gesuperviseerd rangschikken

Protempa supports the construction of software systems for querying clinical databases, summarizing patient data, detecting clinically significant data patterns in groups of patients or individual patients, and extract, transform and load (ETL). Its special feature, temporal abstraction, supports queries and summarization of data in terms of temporal patterns. Temporal patterns enable robust querying and extraction of clinical history. These patterns include frequencies (at least two, three, etc. of some event or observation); sequences (chemotherapy followed by surgery within 180 days, a hospital encounter followed by another hospital encounter within 30 days); and overlaps (falling platelet counts in the setting of HELLP syndrome).

This module provides access to the set of utility classes required to interact with an instance of an AppWorks Gateway from an AppWorks Service. It covers AppWorks dedicated service deployment API, which is a limited subset of the full AppWorks admin API. We currently provide the facility for services to listen to service life-cycle events such as 'service installed', 'service upgraded' and 'service uninstalled'. We also provide the facility for centralised configuration setting management. As AppWorks services are edited from the AppWork Gateway administration console, we provide the ability to respond to updates made here, and also expose creation and update end points for these settings.

This tool allows setting the version number of a specified dependency in a given Maven pom.xml file. All original comments and formatting will be kept. Usage example: mvn com.soerensen.maven.plugins:version-edit-plugin:1.0.1:setDependencyVersion -DpomFile="pom.xml" -Dgavtc="commons-io:commons-io:4.8.0" mvn com.soerensen.maven.plugins:version-edit-plugin:0.0.1:setPropertyDependencyVersion -DpropertyFile="test.property" -Dkey="junit_junit" -Dvalue="24.0.0" gavtc -> groupId:artifactId:version:type*:classifier* * optional Extra property: - noBackupFile (default:false), used to ignore the creation of a backup file.

It helps to quickly make settings for class and its fields of with properties XML. Instead of create a lot of files to describe every class and its fields it use describing by type, by name. E.g. setting "java.lang.Integer"-"INTEGER NOT NULL" will be assigned for every field of this type. Of course it can be overridden by settings for field name and so on. It is used by beige-web to describe how to render an entity and convert from HTML value. It is used by beige-orm to describe how to map an entity to a DBMS. It make simple settings - Map<String, String>, e.g. "title"-"Beige ORM 1.1", class settings Map<String, Map<String, String>>, e.g. "org.model.Customer"-["defaultOrder"-"ITSNAME", "wdgFilterOrder"-"filterOrderStd"], fields settings Map<String, Map<String, Map<String, String>>>, e.g. "org.model.Customer"-["itsId"["wdgNew"-"null", "wdgFilter"-"filterNumber"]]

It helps to quickly make settings for class and its fields of with properties XML. Instead of create a lot of files to describe every class and its fields it use describing by type, by name. E.g. setting "java.lang.Integer"-"INTEGER NOT NULL" will be assigned fo every field of this type. Of course it can be overriden by settings for field name and so on. It is used by beige-web to describe how to render an entity and convert from HTML value. It is used by beige-orm to describe how to map an entity to a DBMS. It make simple settings - Map<String, String>, e.g. "title"-"Beige ORM 1.1", class settings Map<String, Map<String, String>>, e.g. "org.mode.Customer"-["defaultOrder"-"ITSNAME", "wdgFilterOrder"-"filterOrderStd"], fields settings Map<String, Map<String, Map<String, String>>>, e.g. "org.mode.Customer"-["itsId"["wdgNew"-"null", "wdgFilter"-"filterNumber"]]

A Maven Mojo to download and "degenerate" non-maven projects into sources and binaries This MOJO is supposed to scrape and "de-generate" a zip file containing jars into a project's generated-sources folder, skipping items provided in the `src/` folder. It is intended to "mavenize-with-changes" an existing project and allow the user (of the Mojo) to replace classes which they do not have the ability/desire to recompile without setting up a full build. It can also be used to import non-maven projects by not changing anything. The itch I wanted to scratch was mostly to port libGDX to Maven, while replacing the native methods on Matrix4, without rebuilding the whole project. In essence - it's an alternative to patching someone else's project.

How many classes does it take to make a cache? 60? 80? You might think so if you look at the other caches on the market. Ashkay is a streamlined, simple cache that in many ways is more powerful than the other mainstream caches. Ashkay is a strategy based caching tool. In most cases, you might be using a configuration file to tell the cache what rules it should obey. Or, you might just be setting properties on the cache. I have never liked this model as it limits me, the user of the cache to strategies the developer decided were important. Instead, Ashkay lets you choose the strategy(ies) to use when caching certain objects. Of course, a few of the most handy strategies are pre-packaged, but implementing a new one is a simple as can be. Ashkay is a fork of <a href="http://xot.sf.net">xot</a> caching code. Made more sense on its own.

EasyConfig provides simple way to overview and apply settings to file or folder based collections of files. Synonyms to "setting" are property, attribute, value while throughout application "setting" is used. The settings are groupped in "configuration" that is collection of settings from various sources. Main design concepts are: * minimalistic way to describe configuration * pluggable support for data types (validation), setting sources, source handlers Sample use case: An application is deployed in multiple locations. We need to quickly check key settings/parameters and optionally modify some of them. These values are located in different places: - in files directly in file structure - in files inside archive files (optionally nested archives) - values in DB tables - values accessible via URLs - other sources (just guessed: SSH/telnet connection+some command(s), UPnP devices, proprietary protocols, etc) We gather info from any supported (extendable) source and can modify and apply changes if supported by source (e.g. we can't update value that is count of rows in DB table, but we can read that value).

# Pact Spring/JUnit runner ## Overview Library provides ability to play contract tests against a provider using Spring &amp; JUnit. This library is based on and references the JUnit package, so see the [Pact JUnit 4](../pact-jvm-provider-junit) or [Pact JUnit 5](../pact-jvm-provider-junit5) providers for more details regarding configuration using JUnit. Supports: - Standard ways to load pacts from folders and broker - Easy way to change assertion strategy - Spring Test MockMVC Controllers and ControllerAdvice using MockMvc standalone setup. - MockMvc debugger output - Multiple @State runs to test a particular Provider State multiple times - **au.com.dius.pact.provider.junit.State** custom annotation - before each interaction that requires a state change, all methods annotated by `@State` with appropriate the state listed will be invoked. **NOTE:** For publishing provider verification results to a pact broker, make sure the Java system property `pact.provider.version` is set with the version of your provider. ## Example of MockMvc test ```java @RunWith(RestPactRunner.class) // Custom pact runner, child of PactRunner which runs only REST tests @Provider(&quot;myAwesomeService&quot;) // Set up name of tested provider @PactFolder(&quot;pacts&quot;) // Point where to find pacts (See also section Pacts source in documentation) public class ContractTest { //Create an instance of your controller. We cannot autowire this as we&apos;re not using (and don&apos;t want to use) a Spring test runner. @InjectMocks private AwesomeController awesomeController = new AwesomeController(); //Mock your service logic class. We&apos;ll use this to create scenarios for respective provider states. @Mock private AwesomeBusinessLogic awesomeBusinessLogic; //Create an instance of your controller advice (if you have one). This will be passed to the MockMvcTarget constructor to be wired up with MockMvc. @InjectMocks private AwesomeControllerAdvice awesomeControllerAdvice = new AwesomeControllerAdvice(); //Create a new instance of the MockMvcTarget and annotate it as the TestTarget for PactRunner @TestTarget public final MockMvcTarget target = new MockMvcTarget(); @Before //Method will be run before each test of interaction public void before() { //initialize your mocks using your mocking framework MockitoAnnotations.initMocks(this); //configure the MockMvcTarget with your controller and controller advice target.setControllers(awesomeController); target.setControllerAdvice(awesomeControllerAdvice); } @State(&quot;default&quot;, &quot;no-data&quot;) // Method will be run before testing interactions that require &quot;default&quot; or &quot;no-data&quot; state public void toDefaultState() { target.setRunTimes(3); //let&apos;s loop through this state a few times for a 3 data variants when(awesomeBusinessLogic.getById(any(UUID.class))) .thenReturn(myTestHelper.generateRandomReturnData(UUID.randomUUID(), ExampleEnum.ONE)) .thenReturn(myTestHelper.generateRandomReturnData(UUID.randomUUID(), ExampleEnum.TWO)) .thenReturn(myTestHelper.generateRandomReturnData(UUID.randomUUID(), ExampleEnum.THREE)); } @State(&quot;error-case&quot;) public void SingleUploadExistsState_Success() { target.setRunTimes(1); //tell the runner to only loop one time for this state //you might want to throw exceptions to be picked off by your controller advice when(awesomeBusinessLogic.getById(any(UUID.class))) .then(i -&gt; { throw new NotCoolException(i.getArgumentAt(0, UUID.class).toString()); }); } } ``` ## Using a Spring runner (version 3.5.7+) You can use `SpringRestPactRunner` instead of the default Pact runner to use the Spring test annotations. This will allow you to inject or mock spring beans. For example: ```java @RunWith(SpringRestPactRunner.class) @Provider(&quot;pricing&quot;) @PactBroker(protocol = &quot;https&quot;, host = &quot;${pactBrokerHost}&quot;, port = &quot;443&quot;, authentication = @PactBrokerAuth(username = &quot;${pactBrokerUser}&quot;, password = &quot;${pactBrokerPassword}&quot;)) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT) public class PricingServiceProviderPactTest { @MockBean private ProductClient productClient; // This will replace the bean with a mock in the application context @TestTarget @SuppressWarnings(value = &quot;VisibilityModifier&quot;) public final Target target = new HttpTarget(8091); @State(&quot;Product X010000021 exists&quot;) public void setupProductX010000021() throws IOException { reset(productClient); ProductBuilder product = new ProductBuilder() .withProductCode(&quot;X010000021&quot;); when(productClient.fetch((Set&lt;String&gt;) argThat(contains(&quot;X010000021&quot;)), any())).thenReturn(product); } @State(&quot;the product code X00001 can be priced&quot;) public void theProductCodeX00001CanBePriced() throws IOException { reset(productClient); ProductBuilder product = new ProductBuilder() .withProductCode(&quot;X00001&quot;); when(productClient.find((Set&lt;String&gt;) argThat(contains(&quot;X00001&quot;)), any())).thenReturn(product); } } ``` ### Using Spring Context Properties (version 3.5.14+) From version 3.5.14 onwards, the SpringRestPactRunner will look up any annotation expressions (like `${pactBrokerHost}`) above) from the Spring context. For Springboot, this will allow you to define the properties in the application test properties. For instance, if you create the following `application.yml` in the test resources: ```yaml pactbroker: host: &quot;your.broker.local&quot; port: &quot;443&quot; protocol: &quot;https&quot; auth: username: &quot;&lt;your broker username&gt;&quot; password: &quot;&lt;your broker password&gt;&quot; ``` Then you can use the defaults on the `@PactBroker` annotation. ```java @RunWith(SpringRestPactRunner.class) @Provider(&quot;My Service&quot;) @PactBroker( authentication = @PactBrokerAuth(username = &quot;${pactbroker.auth.username}&quot;, password = &quot;${pactbroker.auth.password}&quot;) ) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) public class PactVerificationTest { ``` ### Using a random port with a Springboot test (version 3.5.14+) If you use a random port in a springboot test (by setting `SpringBootTest.WebEnvironment.RANDOM_PORT`), you can use the `SpringBootHttpTarget` which will get the application port from the spring application context. For example: ```java @RunWith(SpringRestPactRunner.class) @Provider(&quot;My Service&quot;) @PactBroker @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) public class PactVerificationTest { @TestTarget public final Target target = new SpringBootHttpTarget(); } ```