Download JAR files tagged by called with all dependencies

YET ANOTHER IMPLEMENTATION OF LEVENSHTEIN DISTANCE GenericLevenshtein is an implementation of Minimum Edit Distance, also called Levenshtein Distance, written by Ramon Ziai and Niels Ott. This algorithm is very popular and it is often used to compute the similarity of strings. The difference in the presented implementation is that it can operate on sequences of any Java object implementing equals(Object). So no matter if you want to compare genome sequences or sequences of numbers, or just strings, here you go! Furthermore, the costs of the replace, insert, and delete operations can be customized by implementing the simple WeightCalculator<T> interface. In that case it is not a requirement to rely on equals(Object) as your implementation can do whatever you like it to do in oder to compare objects.

The Software Testing Automation Framework (STAF) is an open source, multi-platform, multi-language framework designed around the idea of reusable components, called services (such as process invocation, resource management, logging, and monitoring). STAF removes the tedium of building an automation infrastructure, thus enabling you to focus on building your automation solution. The STAF framework provides the foundation upon which to build higher level solutions, and provides a pluggable approach supported across a large variety of platforms and languages. This component contains the STAF Java API (http://staf.sourceforge.net/current/STAFJava.htm ) only. For more information see http://staf.sourceforge.net/ .

Shades is an Object/Relational Mapping (ORM) framework that works in conjunction with JDBC APIs. Instead of relying on XML or annotations for configuration, Shades relies on an interface called ORMapping. This makes shades simple and flexible. Shades has no new transaction model nor Connection management which you must learn. You control the transactions, and the Connection that Shades uses, through plain JDBC interfaces. Shades is designed to work well with modern web development frameworks like Tapestry and Wicket.

This subproject is an extension of the Struts tag library. Each JSP custom tag in this library is a subclass of an associated tag in the Struts tag library. One difference is that this tag library does not use "rtexprvalues", it uses the expression evaluation engine in the Jakarta Taglibs implementation of the JSP Standard Tag Library (version 1.0) to evaluate attribute values. In addition, some of the Struts tags were not ported to this library, as it was determined that their functionality was entirely supplied by the JSTL. These particular Struts tags, and the reason for their non-porting will be described in the documentation for this library. In order to fully understand the correct utilization of this library, you must understand the use and operation of the Struts tag library, and the use and operation of the JavaServer Pages Standard Tag Library (hereafter called the "JSTL"), along with the expression language (sometimes called the "EL") used for evaluating attribute values.

R can use RJava or jsr223 to communicate with java. R also has a class system called R6. If you want to use a java library with native rJava or jsr223 in R there is potentially a lot of glue code needed, and R library specific packaging configuration required. However if you don't mind writing an R-centric API in Java you can generate all of this glue code using a few java annotations and the normal javadoc annotations. This plugin aims to provide an annotation processor that writes that glue code and creates a fairly transparent connection between Java code and R code, with a minimum of hard work. The focus of this is streamlining the creation of R libraries by Java developers, rather than allowing access to arbitrary Java code from R. The ultimate aim of this plugin to allow java developers to provide simple APIs for their libraries, package their library using Maven, push it to github and for that to become seamlessly available as an R library, with a minimal amount of fuss. A focus is on trying to produce CI ready libraries tested with Github workflows and ready for CRAN submission.

Sirix is a temporal storage system effectively and efficiently storing snapshots of time varying (currently semi-structured) data taking full advantage of flash based drives as for instance SSDs. We not only provide several ways of navigating the tree-structure of a single revision, we also support navigation in time. Furthermore we provide a novel storage technique called sliding snapshot to circumvent intermitant full dump snapshots to fast track their in-memory reconstruction and thus we avoiding write peaks and having to read long chains of page fragments/increments/deltas. Sirix uses copy-on-write (COW) as well as an append-only storage making it an ideal candidate for flash based drives while not dropping support for erstwhile disks.

pact-jvm-consumer-specs2 ======================== ## Specs2 Bindings for the pact-jvm library ## Dependency In the root folder of your project in build.sbt add the line: ```scala libraryDependencies += &quot;au.com.dius&quot; %% &quot;pact-jvm-consumer-specs2&quot; % &quot;3.2.11&quot; ``` or if you are using Gradle: ```groovy dependencies { testCompile &quot;au.com.dius:pact-jvm-consumer-specs2_2.11:3.2.11&quot; } ``` __*Note:*__ `PactSpec` requires spec2 3.x. Also, for spray users there&apos;s an incompatibility between specs2 v3.x and spray. Follow these instructions to resolve that problem: https://groups.google.com/forum/#!msg/spray-user/2T6SBp4OJeI/AJlnJuAKPRsJ ## Usage To author a test, mix `PactSpec` into your spec First we define a service client called `ConsumerService`. In our example this is a simple wrapper for `dispatch`, an HTTP client. The source code can be found in the test folder alongside the `ExamplePactSpec`. Here is a simple example: ``` import au.com.dius.pact.consumer.PactSpec class ExamplePactSpec extends Specification with PactSpec { val consumer = &quot;My Consumer&quot; val provider = &quot;My Provider&quot; override def is = uponReceiving(&quot;a request for foo&quot;) .matching(path = &quot;/foo&quot;) .willRespondWith(body = &quot;{}&quot;) .withConsumerTest { providerConfig =&gt; Await.result(ConsumerService(providerConfig.url).simpleGet(&quot;/foo&quot;), Duration(1000, MILLISECONDS)) must beEqualTo(200, Some(&quot;{}&quot;)) } } ``` This spec will be run along with the rest of your specs2 unit tests and will output your pact json to ``` /target/pacts/&lt;Consumer&gt;_&lt;Provider&gt;.json ``` # 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`.

pact-jvm-consumer-specs2 ======================== ## Specs2 Bindings for the pact-jvm library ## Dependency In the root folder of your project in build.sbt add the line: ```scala libraryDependencies += &quot;au.com.dius&quot; %% &quot;pact-jvm-consumer-specs2&quot; % &quot;3.2.11&quot; ``` or if you are using Gradle: ```groovy dependencies { testCompile &quot;au.com.dius:pact-jvm-consumer-specs2_2.11:3.2.11&quot; } ``` __*Note:*__ `PactSpec` requires spec2 3.x. Also, for spray users there&apos;s an incompatibility between specs2 v3.x and spray. Follow these instructions to resolve that problem: https://groups.google.com/forum/#!msg/spray-user/2T6SBp4OJeI/AJlnJuAKPRsJ ## Usage To author a test, mix `PactSpec` into your spec First we define a service client called `ConsumerService`. In our example this is a simple wrapper for `dispatch`, an HTTP client. The source code can be found in the test folder alongside the `ExamplePactSpec`. Here is a simple example: ``` import au.com.dius.pact.consumer.PactSpec class ExamplePactSpec extends Specification with PactSpec { val consumer = &quot;My Consumer&quot; val provider = &quot;My Provider&quot; override def is = uponReceiving(&quot;a request for foo&quot;) .matching(path = &quot;/foo&quot;) .willRespondWith(body = &quot;{}&quot;) .withConsumerTest { providerConfig =&gt; Await.result(ConsumerService(providerConfig.url).simpleGet(&quot;/foo&quot;), Duration(1000, MILLISECONDS)) must beEqualTo(200, Some(&quot;{}&quot;)) } } ``` This spec will be run along with the rest of your specs2 unit tests and will output your pact json to ``` /target/pacts/&lt;Consumer&gt;_&lt;Provider&gt;.json ```

pact-jvm-consumer-specs2 ======================== ## Specs2 Bindings for the pact-jvm library ## Dependency In the root folder of your project in build.sbt add the line: ```scala libraryDependencies += &quot;au.com.dius&quot; %% &quot;pact-jvm-consumer-specs2&quot; % &quot;3.2.2&quot; ``` or if you are using Gradle: ```groovy dependencies { testCompile &quot;au.com.dius:pact-jvm-consumer-specs2_2.11:3.2.2&quot; } ``` __*Note:*__ `PactSpec` requires spec2 3.x. Also, for spray users there&apos;s an incompatibility between specs2 v3.x and spray. Follow these instructions to resolve that problem: https://groups.google.com/forum/#!msg/spray-user/2T6SBp4OJeI/AJlnJuAKPRsJ ## Usage To author a test, mix `PactSpec` into your spec First we define a service client called `ConsumerService`. In our example this is a simple wrapper for `dispatch`, an HTTP client. The source code can be found in the test folder alongside the `ExamplePactSpec`. Here is a simple example: ``` import au.com.dius.pact.consumer.PactSpec class ExamplePactSpec extends Specification with PactSpec { val consumer = &quot;My Consumer&quot; val provider = &quot;My Provider&quot; override def is = uponReceiving(&quot;a request for foo&quot;) .matching(path = &quot;/foo&quot;) .willRespondWith(body = &quot;{}&quot;) .withConsumerTest { providerConfig =&gt; Await.result(ConsumerService(providerConfig.url).simpleGet(&quot;/foo&quot;), Duration(1000, MILLISECONDS)) must beEqualTo(200, Some(&quot;{}&quot;)) } } ``` This spec will be run along with the rest of your specs2 unit tests and will output your pact json to ``` /target/pacts/&lt;Consumer&gt;_&lt;Provider&gt;.json ```

DICTIONARY-BASED COMPOUND SPLITTER FOR GERMAN BananaSplit is a compound splitter for German that uses a dictionary resource. The dictionary can be either a simple word list, or a word list equipped with POS values, or an XML based dictionary. The original version was able to use GermaNet as a dictionary. This is useful in applications that rely on GermaNet anyway: no additional lexicon needs to be generated and held in memory. This was also the original purpose of BananaSplit. It served as a compound splitter for a tool called BananaRelation. BananaRelation cannot be published here as it makes heavy use of unpublished code by EML Research, Heidelberg. BananaSplit can either be used as a standalone application or it can be integrated into other Java programs (as a library). This program emerged from the seminar Lexical Semantic Processing in NLP (winter term 2005/2006) taught by Iryna Gurevych at the Seminar für Sprachwissenschaft, Tübingen. Both BananaSplit and BananaRelation were introduced to the seminar participants on 17th of December, 2005. The key algorithm for compound splitting is based on Langer (1998). The program came to use in Müller and Gurevych (2006). Please note that the program splits compounds into two parts only. Details are given in the documents linked below.