Download JAR files tagged by $http: with all dependencies

A platform for discovery and communication between various parts of a distributed service or application. At its minimum, the platform is a library which can be used to serialize and deserialize application constructs into payloads which it can then send to and receive from remote endpoints. For now it supports TCP and HTTP communication protocols with WebSockets coming soon. It supports raw byte streams via TCP, as well as application/json via JAX-RS as serialization protocols. It offers plain or SSL/TLS communication for security of your data in transit. For now it is only available in Java, with bindings for other languages coming soon. The communication pattern is request-reply, with fail fast semantics, and with service consumers (clients) knowing beforehand the coordinates of the service providers (servers). The TCP communication protocol offers blocking/unblocking/asynchronous flavors whereas the rest are only blocking for now. Coming soon, the platform will provide a Discovery Service to facilitate the registration of the service providers (servers) and service consumers (clients). In this case, the callers don't need to resolve or even balance their calls towards various endpoints, since the Platform handles this tasks. In this case, the pub/sub communication pattern will also be available (coming soon) with at-most-once delivery guarantees. We intend to provide a Security Service for managing the keys/and certificates of various services as well as Metrics and Logging services (coming soon).

This project aims to offer an easy-to-extend Java DAS server framework. It offers several advantages: * Implementing data sources is very easy but also flexible and powerful. * Data caching is built into the system, with access to the caching mechanism made available to the data sources. * All aspects of the server are highly configurable, including selecting options where the DAS 1.53 specification offers choices to the implementor. * The latest Java technologies have been used throughout the system to optimise performance and simplify data source development. * Wherever possible the same terminology is used in the API as in the DAS specification and XML - again, making data source development more easy. * The server allows XSLT transforms of the DAS XML to be configured to provide a simple DAS client view (limited to the single DAS source). More details of the DAS protocol, DAS servers and DAS clients can be found at http://www.biodas.org/wiki/Main_Page. The first version of this server is a complete implementation of Distributed Sequence Annotation System (DAS) Version 1.53. If you are interested in learning more about DAS 1.53, the specification is highly recommended as a concise and complete description of the DAS protocol that can be obtained from: http://biodas.org/documents/spec.html

Apache Commons Crypto is a cryptographic library optimized with AES-NI (Advanced Encryption Standard New Instructions). It provides Java API for both cipher level and Java stream level. Developers can use it to implement high performance AES encryption/decryption with the minimum code and effort. Please note that Crypto doesn't implement the cryptographic algorithm such as AES directly. It wraps to OpenSSL or JCE which implement the algorithms. Features -------- 1. Cipher API for low level cryptographic operations. 2. Java stream API (CryptoInputStream/CryptoOutputStream) for high level stream encryption/decryption. 3. Both optimized with high performance AES encryption/decryption. (1400 MB/s - 1700 MB/s throughput in modern Xeon processors). 4. JNI-based implementation to achieve comparable performance to the native C/C++ version based on OpenSsl. 5. Portable across various operating systems (currently only Linux/MacOSX/Windows); Apache Commons Crypto loads the library according to your machine environment (it checks system properties, `os.name` and `os.arch`). 6. Simple usage. Add the commons-crypto-(version).jar file to your classpath. Export restrictions ------------------- This distribution includes cryptographic software. The country in which you currently reside may have restrictions on the import, possession, use, and/or re-export to another country, of encryption software. BEFORE using any encryption software, please check your country's laws, regulations and policies concerning the import, possession, or use, and re-export of encryption software, to see if this is permitted. See <http://www.wassenaar.org/> for more information. The U.S. Government Department of Commerce, Bureau of Industry and Security (BIS), has classified this software as Export Commodity Control Number (ECCN) 5D002.C.1, which includes information security software using or performing cryptographic functions with asymmetric algorithms. The form and manner of this Apache Software Foundation distribution makes it eligible for export under the License Exception ENC Technology Software Unrestricted (TSU) exception (see the BIS Export Administration Regulations, Section 740.13) for both object code and source code. The following provides more details on the included cryptographic software: * Commons Crypto use [Java Cryptography Extension](http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html) provided by Java * Commons Crypto link to and use [OpenSSL](https://www.openssl.org/) ciphers

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.pact.consumer&quot; %% &quot;specs2&quot; % &quot;4.0.1&quot; ``` or if you are using Gradle: ```groovy dependencies { testCompile &quot;au.com.dius.pact.consumer:specs2_2.13:4.0.1&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`. # Test Analytics We are tracking anonymous analytics to gather important usage statistics like JVM version and operating system. To disable tracking, set the &apos;pact_do_not_track&apos; system property or environment variable to &apos;true&apos;.

Provides the support for <a href="https://tagmycode.com">TagMyCode</a>. This plugin allows you to manage your own snippets.<br/> <br/> Features:<br/> * Add snippets: you can save your code snippets including description, language, and tags<br/> * List snippets (CRUD): snippets are stored locally and you can filter, sort, create, modify, edit or delete them directly from the IDE<br/> * Quick search: you can search your snippets and insert them directly into the document<br/> <br/> CHANGELOG:<br/> <br/> 2.3.0 (released 2020-07-26)<br/> * published plugin into Apache NetBeans Plugin Portal<br/> * filter snippets by languages<br/> <br/> 2.2.1 (released 2018-01-10)<br/> * Quick Search dialog is now resizable</br> * fixed syntax highlight for PHP and HTML</br> * if refresh token is not valid user will be automatically logged out</br> </br> 2.2.0 (released 2017-11-06)<br/> * snippets management works in offline mode<br/> * autodetect language on new snippet<br/> * added settings dialog with editor theme and font size option<br/> * added title and description to snippet view<br/> * changed open browser class<br/> * text can be dragged into table to create a new snippet<br/> * snippets can be dragged directly into editor and the code are copied<br/> * added "save as file" feature<br/> * added "clone snippet" feature<br/> * added "snippet properties" dialog<br/> * detect binary file<br/> <br/> 2.1.0 (released 2017-04-24)<br/> * moved error messages from dialog to Netbeans Notification Log<br/> * added welcome panel<br/> * about dialog shows plugin version and framework version<br/> * moved storage from JSON to SQL<br/> <br/> 2.0 (released 2016-07-11)<br/> * new user interface<br/> * list of snippets stored locally<br/> * syntax highlight powered by <a href="http://bobbylight.github.io/RSyntaxTextArea/">RSyntaxTextArea</a><br/> * snippets are synchronized with server<br/> * filter snippets<br/> * quick search feature<br/> * insert selected snippet at cursor in document<br/> <br/> 1.1.3 (released 2015-12-18)<br/> * Fix for NetBeans 8.1<br/> <br/> 1.1.2 (released 2014-10-03)<br/> * Switched authentication from OAuth 1.0a to OAuth 2<br/> * Console write also snippet title when new snippet is created (thanks to bejoy)<br/> <br/> 1.1 (released 2014-08-19)<br/> * Added "Search snippets" feature<br/> * Fixed some minor bugs<br/> <br/> 1.0 (released 2014-04-14)<br/> * First release with feature "Create snippet"<br/>

Jsgen is a Java Source Generation Framework: That means, it should be a valuable tool, if you intend to write a custom generator for Java sources. As such, it is the successor of a previous framework, called JaxMeJS (http://jaxme.sourceforge.net/JaxMeJS/docs/index.html). The predecessor came into being as a standalone project. It was incorporated into the bigger JaxMe project, when the latter was adopted by the Apache Webservices project. And it was buried as part of the bigger project, when the latter was moved to the Apache Attic (http://svn.apache.org/repos/asf/webservices/archive/jaxme/). That was fine for quite some time, because the latest released version (JaxMeJS 0.5.2) did its job quite well. Over the years, however, the Java language has evolved, and the lack of support for features like Generics, or Annotations, became a burden. Hence the Successor: Jsgen picks up, where JaxMeJS ended. It is, however, a complete rewrite with several additional features, that the author considers to be important for modern Java applications: 1. It supports Generics. 2. It supports Annotations. 3. The builder pattern has been adopted. Almost all important classes are implemented as builders. This should make writing the actual source generators much more concise, and maintainable, than it used to be before. 4. The code style is configurable. Code styles allow you to concentrate on the actual work. The resulting Jave source will look nicely formatted, anyways. As of this writing, you can select between two builtin code styles: - The default code style is basically the authors personal free style, roughly comparable to the default code style of the Eclipse Java IDE. - As an alternative, there is also a Maven code style, which is widely used in the Open Source communities. Compared to the default style, it is less concise, if not even a bit verbose. On the other hand, it is widely adopted by projects in the vicinity of {{{https://maven.apache.org}Apache Maven}}. 5. Import lists are created, and sorted, automatically.

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