Download JAR files tagged by matching with all dependencies
dhelm-candlepattern from group in.kncsolutions.dhelm.candlepattern (version 1.0.4)
This library provides the necessary implementations to screen the following patterns:
Bullish Belt Hold
Bearish Belt Hold
Hammer
Hanging Man
Southern Doji
Northern Doji
Gapping Up Doji
Gapping Down Doji
Takuri Line
One Candle Shooting Star
Bullish Strong Line
Bearish Strong Line
Bullish Harami
Bearish Harami
Bullish Engulfing
Bearish Engulfing
Bullish Kicking
Bearish Kicking
Matching Low
Matching High
Bullish Harami Cross
Bearish Harami Cross
Bullish Doji Star
Bearish Doji Star
Dark Cloud Cover
Piercing Line
Descending Hawk
Homing Pigeon
Bullish Abandoned Baby
Bearish Abandoned Baby
Three Inside Up
Three Inside Down
Three Outside Up
Three Outside Down
Three White Soldiers
Three Black Crows
Morning Doji Star
Evening Doji Star
Morning Star
Evening Star
Upside Tasuki Gap
Downside Tasuki Gap
Bullish Side by Side White Lines
Bearish Side by Side White Lines
Rising Three Method
Group: in.kncsolutions.dhelm.candlepattern Artifact: dhelm-candlepattern
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact dhelm-candlepattern
Group in.kncsolutions.dhelm.candlepattern
Version 1.0.4
Last update 16. July 2018
Organization KNC Solutions Private Limited.
URL https://dhelm.kncsolutions.in
License The Apache Software License, Version 2.0
Dependencies amount 3
Dependencies dhelm-exceptions, dhelm-mathcal, dhelm-candlebasic,
There are maybe transitive dependencies!
Group in.kncsolutions.dhelm.candlepattern
Version 1.0.4
Last update 16. July 2018
Organization KNC Solutions Private Limited.
URL https://dhelm.kncsolutions.in
License The Apache Software License, Version 2.0
Dependencies amount 3
Dependencies dhelm-exceptions, dhelm-mathcal, dhelm-candlebasic,
There are maybe transitive dependencies!
jburg from group net.sourceforge.jburg (version 1.10.3)
A bottom-up rewrite machine is a compiler construction tool that is often used in the compiler's back end to
convert a tree-structured representation of a program into machine code -- or, in Java's case, bytecode.
JBurg can also be used as a general-purpose dynamic programming engine. JBurg is descended from iburg-class
BURGs, described in Fraser, Hanson, and Proebsting's paper, "Engineering a Simple, Efficient Code Generator
Generator."
JBurg brings similar O(N) minimum-cost tree rewriting capabilities to Java, and also allows the programmer to
specify transitions between non-terminal states, that are significantly more powerful than iburg's transitive
closures: JBurg transformation rules allow the transformation to inject additional program logic, which makes
a JBurg specification more like a grammar than like a list of pattern-matching rules.
0 downloads
Artifact jburg
Group net.sourceforge.jburg
Version 1.10.3
Last update 24. February 2016
Organization not specified
URL http://jburg.sourceforge.net/
License Common Public License Version 1.0
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!
Group net.sourceforge.jburg
Version 1.10.3
Last update 24. February 2016
Organization not specified
URL http://jburg.sourceforge.net/
License Common Public License Version 1.0
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!
jadex-rules-base from group org.activecomponents.jadex (version 4.0.267)
Jadex Rules is a small lightweight rule engine, which currently employs the well-known Rete algorithm for highly efficient rule matching. Jadex rules is therefore similar to other rule engines like JESS and Drools. Despite the similarities there are also important differences between these systems:
* Jadex Rules is very small and intended to be used as component of other software. Even though rules can be specified in a Java dialect as well as (a small variation of) the CLIPS language its primary usage is on the API level. Jadex Rules is currently the core component of the Jadex BDI reasoning engine.
* Jadex Rules cleanly separates between state and rule representation. This allows the state implementation as well as the matcher to be flexibly exchanged. Some experiments have e.g. been conducted with a Jena representation. Regarding the matcher, it is planned to support also the Treat algorithm, which has a lower memory footprint than Rete.
* Jadex Rules pays close attention to rule debugging. The state as well as the rete engine can be observed at runtime. The rule debugger provides functionalities to execute a rule program stepwise and also use rule breakpoints to stop the execution at those points.
Group: org.activecomponents.jadex Artifact: jadex-rules-base
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact jadex-rules-base
Group org.activecomponents.jadex
Version 4.0.267
Last update 08. September 2022
Organization not specified
URL https://www.activecomponents.org
License GPL-3.0
Dependencies amount 4
Dependencies jadex-util-commons, jadex-util-concurrent, jadex-serialization-xml, antlr-runtime,
There are maybe transitive dependencies!
Group org.activecomponents.jadex
Version 4.0.267
Last update 08. September 2022
Organization not specified
URL https://www.activecomponents.org
License GPL-3.0
Dependencies amount 4
Dependencies jadex-util-commons, jadex-util-concurrent, jadex-serialization-xml, antlr-runtime,
There are maybe transitive dependencies!
jadex-rules from group org.activecomponents.jadex (version 3.0.117)
Jadex Rules is a small lightweight rule engine, which currently employs the well-known Rete algorithm for highly efficient rule matching. Jadex rules is therefore similar to other rule engines like JESS and Drools. Despite the similarities there are also important differences between these systems:
* Jadex Rules is very small and intended to be used as component of other software. Even though rules can be specified in a Java dialect as well as (a small variation of) the CLIPS language its primary usage is on the API level. Jadex Rules is currently the core component of the Jadex BDI reasoning engine.
* Jadex Rules cleanly separates between state and rule representation. This allows the state implementation as well as the matcher to be flexibly exchanged. Some experiments have e.g. been conducted with a Jena representation. Regarding the matcher, it is planned to support also the Treat algorithm, which has a lower memory footprint than Rete.
* Jadex Rules pays close attention to rule debugging. The state as well as the rete engine can be observed at runtime. The rule debugger provides functionalities to execute a rule program stepwise and also use rule breakpoints to stop the execution at those points.
Group: org.activecomponents.jadex Artifact: jadex-rules
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact jadex-rules
Group org.activecomponents.jadex
Version 3.0.117
Last update 10. May 2020
Organization not specified
URL https://www.activecomponents.org
License GPL-3.0
Dependencies amount 3
Dependencies jadex-commons, jadex-xml, antlr-runtime,
There are maybe transitive dependencies!
Group org.activecomponents.jadex
Version 3.0.117
Last update 10. May 2020
Organization not specified
URL https://www.activecomponents.org
License GPL-3.0
Dependencies amount 3
Dependencies jadex-commons, jadex-xml, antlr-runtime,
There are maybe transitive dependencies!
pact-jvm-consumer-specs2_2.12 from group au.com.dius (version 4.0.10)
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 += "au.com.dius" %% "pact-jvm-consumer-specs2" % "3.2.11"
```
or if you are using Gradle:
```groovy
dependencies {
testCompile "au.com.dius:pact-jvm-consumer-specs2_2.11:3.2.11"
}
```
__*Note:*__ `PactSpec` requires spec2 3.x. Also, for spray users there'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 = "My Consumer"
val provider = "My Provider"
override def is = uponReceiving("a request for foo")
.matching(path = "/foo")
.willRespondWith(body = "{}")
.withConsumerTest { providerConfig =>
Await.result(ConsumerService(providerConfig.url).simpleGet("/foo"), Duration(1000, MILLISECONDS)) must beEqualTo(200, Some("{}"))
}
}
```
This spec will be run along with the rest of your specs2 unit tests and will output your pact json to
```
/target/pacts/<Consumer>_<Provider>.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`.
Group: au.com.dius Artifact: pact-jvm-consumer-specs2_2.12
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact pact-jvm-consumer-specs2_2.12
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 5
Dependencies pact-jvm-consumer, json, specs2-core_2.12, async-http-client, scala-java8-compat_2.12,
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 5
Dependencies pact-jvm-consumer, json, specs2-core_2.12, async-http-client, scala-java8-compat_2.12,
There are maybe transitive dependencies!
pact-jvm-consumer-specs2_2.11 from group au.com.dius (version 3.5.24)
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 += "au.com.dius" %% "pact-jvm-consumer-specs2" % "3.2.11"
```
or if you are using Gradle:
```groovy
dependencies {
testCompile "au.com.dius:pact-jvm-consumer-specs2_2.11:3.2.11"
}
```
__*Note:*__ `PactSpec` requires spec2 3.x. Also, for spray users there'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 = "My Consumer"
val provider = "My Provider"
override def is = uponReceiving("a request for foo")
.matching(path = "/foo")
.willRespondWith(body = "{}")
.withConsumerTest { providerConfig =>
Await.result(ConsumerService(providerConfig.url).simpleGet("/foo"), Duration(1000, MILLISECONDS)) must beEqualTo(200, Some("{}"))
}
}
```
This spec will be run along with the rest of your specs2 unit tests and will output your pact json to
```
/target/pacts/<Consumer>_<Provider>.json
```
Group: au.com.dius Artifact: pact-jvm-consumer-specs2_2.11
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact pact-jvm-consumer-specs2_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 10
Dependencies kotlin-stdlib-jdk8, kotlin-reflect, slf4j-api, groovy-all, kotlin-logging, scala-library, scala-logging_2.11, pact-jvm-consumer_2.11, specs2-core_2.11, async-http-client,
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 10
Dependencies kotlin-stdlib-jdk8, kotlin-reflect, slf4j-api, groovy-all, kotlin-logging, scala-library, scala-logging_2.11, pact-jvm-consumer_2.11, specs2-core_2.11, async-http-client,
There are maybe transitive dependencies!
pact-jvm-consumer-specs2_2.10 from group au.com.dius (version 2.4.20)
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 += "au.com.dius" %% "pact-jvm-consumer-specs2" % "3.2.2"
```
or if you are using Gradle:
```groovy
dependencies {
testCompile "au.com.dius:pact-jvm-consumer-specs2_2.11:3.2.2"
}
```
__*Note:*__ `PactSpec` requires spec2 3.x. Also, for spray users there'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 = "My Consumer"
val provider = "My Provider"
override def is = uponReceiving("a request for foo")
.matching(path = "/foo")
.willRespondWith(body = "{}")
.withConsumerTest { providerConfig =>
Await.result(ConsumerService(providerConfig.url).simpleGet("/foo"), Duration(1000, MILLISECONDS)) must beEqualTo(200, Some("{}"))
}
}
```
This spec will be run along with the rest of your specs2 unit tests and will output your pact json to
```
/target/pacts/<Consumer>_<Provider>.json
```
Group: au.com.dius Artifact: pact-jvm-consumer-specs2_2.10
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact pact-jvm-consumer-specs2_2.10
Group au.com.dius
Version 2.4.20
Last update 14. April 2018
Organization not specified
URL https://github.com/DiUS/pact-jvm
License Apache 2
Dependencies amount 4
Dependencies slf4j-api, scala-library, pact-jvm-consumer_2.10, specs2-core_2.10,
There are maybe transitive dependencies!
Group au.com.dius
Version 2.4.20
Last update 14. April 2018
Organization not specified
URL https://github.com/DiUS/pact-jvm
License Apache 2
Dependencies amount 4
Dependencies slf4j-api, scala-library, pact-jvm-consumer_2.10, specs2-core_2.10,
There are maybe transitive dependencies!
jadex-rules from group net.sourceforge.jadex (version 2.4)
Jadex Rules is a small lightweight rule engine, which currently
employs the well-known Rete algorithm for highly efficient rule
matching. Jadex rules is therefore similar to other rule engines
like JESS and Drools. Despite the similarities there are also
important differences between these systems:
* Jadex Rules is very small and
intended to be used as component
of other software. Even though rules can be specified in a Java
dialect as well as (a small variation of) the CLIPS language
its primary usage is on the API level. Jadex Rules is currently
the core component of the Jadex BDI reasoning engine.
* Jadex Rules cleanly separates between state and rule representation.
This allows the state implementation as well as the matcher to be
flexibly exchanged. Some experiments have e.g. been conducted with
a Jena representation. Regarding the matcher, it is planned to
support also the Treat algorithm, which has a lower memory footprint
than Rete.
* Jadex Rules pays close attention to rule debugging. The state as
well as the rete engine can be observed at runtime. The rule debugger
provides functionalities to execute a rule program stepwise and also
use rule breakpoints to stop the execution at those points.
0 downloads
Artifact jadex-rules
Group net.sourceforge.jadex
Version 2.4
Last update 20. December 2013
Organization not specified
URL Not specified
License not specified
Dependencies amount 3
Dependencies jadex-commons, jadex-xml, antlr-runtime,
There are maybe transitive dependencies!
Group net.sourceforge.jadex
Version 2.4
Last update 20. December 2013
Organization not specified
URL Not specified
License not specified
Dependencies amount 3
Dependencies jadex-commons, jadex-xml, antlr-runtime,
There are maybe transitive dependencies!
specs2_2.13 from group au.com.dius.pact.consumer (version 4.2.21)
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 += "au.com.dius.pact.consumer" %% "specs2" % "4.0.1"
```
or if you are using Gradle:
```groovy
dependencies {
testCompile "au.com.dius.pact.consumer:specs2_2.13:4.0.1"
}
```
__*Note:*__ `PactSpec` requires spec2 3.x. Also, for spray users there'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 = "My Consumer"
val provider = "My Provider"
override def is = uponReceiving("a request for foo")
.matching(path = "/foo")
.willRespondWith(body = "{}")
.withConsumerTest { providerConfig =>
Await.result(ConsumerService(providerConfig.url).simpleGet("/foo"), Duration(1000, MILLISECONDS)) must beEqualTo(200, Some("{}"))
}
}
```
This spec will be run along with the rest of your specs2 unit tests and will output your pact json to
```
/target/pacts/<Consumer>_<Provider>.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`.
# Test Analytics
We are tracking anonymous analytics to gather important usage statistics like JVM version
and operating system. To disable tracking, set the 'pact_do_not_track' system property or environment
variable to 'true'.
Group: au.com.dius.pact.consumer Artifact: specs2_2.13
Show all versions Show documentation Show source
Show all versions Show documentation Show source
0 downloads
Artifact specs2_2.13
Group au.com.dius.pact.consumer
Version 4.2.21
Last update 13. May 2022
Organization not specified
URL https://github.com/DiUS/pact-jvm
License Apache 2
Dependencies amount 5
Dependencies consumer, json, specs2-core_2.13, async-http-client, scala-java8-compat_2.13,
There are maybe transitive dependencies!
Group au.com.dius.pact.consumer
Version 4.2.21
Last update 13. May 2022
Organization not specified
URL https://github.com/DiUS/pact-jvm
License Apache 2
Dependencies amount 5
Dependencies consumer, json, specs2-core_2.13, async-http-client, scala-java8-compat_2.13,
There are maybe transitive dependencies!
pact-jvm-consumer-junit5_2.11 from group au.com.dius (version 3.5.24)
pact-jvm-consumer-junit5
========================
JUnit 5 support for Pact consumer tests
## Dependency
The library is available on maven central using:
* group-id = `au.com.dius`
* artifact-id = `pact-jvm-consumer-junit5_2.12`
* version-id = `3.5.x`
## Usage
### 1. Add the Pact consumer test extension to the test class.
To write Pact consumer tests with JUnit 5, you need to add `@ExtendWith(PactConsumerTestExt)` to your test class. This
replaces the `PactRunner` used for JUnit 4 tests. The rest of the test follows a similar pattern as for JUnit 4 tests.
```java
@ExtendWith(PactConsumerTestExt.class)
class ExampleJavaConsumerPactTest {
```
### 2. create a method annotated with `@Pact` that returns the interactions for the test
For each test (as with JUnit 4), you need to define a method annotated with the `@Pact` annotation that returns the
interactions for the test.
```java
@Pact(provider="test_provider", consumer="test_consumer")
public RequestResponsePact createPact(PactDslWithProvider builder) {
return builder
.given("test state")
.uponReceiving("ExampleJavaConsumerPactTest test interaction")
.path("/")
.method("GET")
.willRespondWith()
.status(200)
.body("{\"responsetest\": true}")
.toPact();
}
```
### 3. Link the mock server with the interactions for the test with `@PactTestFor`
Then the final step is to use the `@PactTestFor` annotation to tell the Pact extension how to setup the Pact test. You
can either put this annotation on the test class, or on the test method. For examples see
[ArticlesTest](src/test/java/au/com/dius/pact/consumer/junit5/ArticlesTest.java) and
[MultiTest](src/test/groovy/au/com/dius/pact/consumer/junit5/MultiTest.groovy).
The `@PactTestFor` annotation allows you to control the mock server in the same way as the JUnit 4 `PactProviderRule`. It
allows you to set the hostname to bind to (default is `localhost`) and the port (default is to use a random port). You
can also set the Pact specification version to use (default is V3).
```java
@ExtendWith(PactConsumerTestExt.class)
@PactTestFor(providerName = "ArticlesProvider", port = "1234")
public class ExampleJavaConsumerPactTest {
```
**NOTE on the hostname**: The mock server runs in the same JVM as the test, so the only valid values for hostname are:
| hostname | result |
| -------- | ------ |
| `localhost` | binds to the address that localhost points to (normally the loopback adapter) |
| `127.0.0.1` or `::1` | binds to the loopback adapter |
| host name | binds to the default interface that the host machines DNS name resolves to |
| `0.0.0.0` or `::` | binds to the all interfaces on the host machine |
#### Matching the interactions by provider name
If you set the `providerName` on the `@PactTestFor` annotation, then the first method with a `@Pact` annotation with the
same provider name will be used. See [ArticlesTest](src/test/java/au/com/dius/pact/consumer/junit5/ArticlesTest.java) for
an example.
#### Matching the interactions by method name
If you set the `pactMethod` on the `@PactTestFor` annotation, then the method with the provided name will be used (it still
needs a `@Pact` annotation). See [MultiTest](src/test/groovy/au/com/dius/pact/consumer/junit5/MultiTest.groovy) for an example.
### Injecting the mock server into the test
You can get the mock server injected into the test method by adding a `MockServer` parameter to the test method.
```java
@Test
void test(MockServer mockServer) {
HttpResponse httpResponse = Request.Get(mockServer.getUrl() + "/articles.json").execute().returnResponse();
assertThat(httpResponse.getStatusLine().getStatusCode(), is(equalTo(200)));
}
```
This helps with getting the base URL of the mock server, especially when a random port is used.
## Unsupported
The current implementation does not support tests with multiple providers. This will be added in a later release.
Group: au.com.dius Artifact: pact-jvm-consumer-junit5_2.11
Show all versions Show documentation Show source
Show all versions Show documentation Show source
1 downloads
Artifact pact-jvm-consumer-junit5_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 9
Dependencies kotlin-stdlib-jdk8, kotlin-reflect, slf4j-api, groovy-all, kotlin-logging, scala-library, scala-logging_2.11, pact-jvm-consumer_2.11, junit-jupiter-api,
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 9
Dependencies kotlin-stdlib-jdk8, kotlin-reflect, slf4j-api, groovy-all, kotlin-logging, scala-library, scala-logging_2.11, pact-jvm-consumer_2.11, junit-jupiter-api,
There are maybe transitive dependencies!
Page 24 from 27 (items total 269)