Download JAR files tagged by results with all dependencies

The XRadar is an open extensible code report tool currently supporting all Java based systems. The batch-processing framework produces HTML/SVG reports of the systems current state and the development over time - all presented in sexy tables and graphs. It gets results from several brilliant open source projects and a couple of in house grown projects and presents the results as massive unified html/svg reports. The architecture is based on java, xml and xsl. Presently it only supports Java, but there are plans to produce plug ins for other leading languages.

ThreadFix is a software vulnerability aggregation and management system that reduces the time it takes to fix software vulnerabilities. ThreadFix imports the results from dynamic, static and manual testing to provide a centralized view of software security defects across development teams and applications. The system allows companies to correlate testing results and streamline software remediation efforts by simplifying feeds to software issue trackers. By auto generating application firewall rules, this tool allows organizations to continue remediation work uninterrupted. ThreadFix empowers managers with vulnerability trending reports that show progress over time, giving them justification for their efforts. ThreadFix is developed and maintained by Denim Group, Ltd (http://www.denimgroup.com) For information about commercial support and other services, contact Denim Group about ThreadFix http://www.denimgroup.com/threadfix/ The ASTAM Correlator is a branch of the public Community Edition of the ThreadFix software. This branch is maintained by Secure Decisions (http://www.securedecisions.com), a Division of Applied Visions, Inc (http://www.avi.com).

Tool used to generate the preferred class information for downloadable JAR files in the form of a META-INF/PREFERRED.LIST required for use by the {@link net.jini.loader.pref.PreferredClassLoader}. The list is generated by examining the dependencies of classes contained within a target JAR file and zero or more additional supporting JAR files. Through various command-line options, a set of "root" classes are identified as belonging to a public API. These root classes provide the starting point for recursively computing a dependency graph, finding all of the classes referenced in the public API of the root classes, finding all of the classes referenced in turn by the public API of those classes, and so on, until no new classes are found. The results of the dependency analysis are combined with the preferred list information in the additional supporting JAR files to compute a preferred list having the smallest number of entries that describes the preferred state of the classes and resources contained in all of the JAR files. The output of the tool is a new version of the target JAR file containing the generated preferred list, and/or a copy of the list printed to System.out.

This module defines the interface for AlignmentAlgorithms as well as some helper classes. An AlignmentAlgorithm computes an Alignment of two given input sequences, given a Comparator that works in these sequences. More details on the AlignmentAlgorithm can be found in the respective interface. More information on Comparators can be found in the comparators module. The resulting 'Alignment' may be just a real-valued dissimilarity between the input sequence or may incorporate additional information, such as a full Alignment, a PathList, a PathMap or a CooptimalModel. If those results support the calculation of a Gradient, they implement the DerivableAlignmentDistance interface. In more detail, the Alignment class represents the result of a backtracing scheme, listing all Operations that have been applied in one co-optimal Alignment. A classic AlignmentAlgorithm does not result in a differentiable dissimilarity, because the minimum function is not differentiable. Therefore, this package also contains utility functions for a soft approximation of the minimum function, namely Softmin. For faster (parallel) computation of many different alignments or gradients we also provide the ParallelProcessingEngine, the SquareParallelProcessingEngine and the ParallelGradientEngine.

ThreadFix is a software vulnerability aggregation and management system that reduces the time it takes to fix software vulnerabilities. ThreadFix imports the results from dynamic, static and manual testing to provide a centralized view of software security defects across development teams and applications. The system allows companies to correlate testing results and streamline software remediation efforts by simplifying feeds to software issue trackers. By auto generating application firewall rules, this tool allows organizations to continue remediation work uninterrupted. ThreadFix empowers managers with vulnerability trending reports that show progress over time, giving them justification for their efforts. ThreadFix is developed and maintained by Denim Group, Ltd (http://www.denimgroup.com) For information about commercial support and other services, contact Denim Group about ThreadFix http://www.denimgroup.com/resources-threadfix/

Randoop is an automatic unit test generator for Java. It automatically creates unit tests for your classes, in JUnit format. Randoop generates unit tests using feedback-directed random test generation. In a nutshell, this technique randomly, but smartly, generates sequences of methods and constructor invocations for the classes under test, and uses the sequences to create tests. Randoop executes the sequences it creates, using the results of the execution to create assertions that capture the behavior or your program and that catch bugs. Randoop has created tests that find previously unkwon errors even in widely-used libraries including Sun and IBM's JDKs. A .NET version of Randoop, used internally at Microsoft, has been used successfully by a team of test engineers to find errors in a core .NET component that has been heavily tested for years. Randoop's combination of randomized test generation and test execution results in a highly effective test generation technique.

Spring LDAP is a Java library for simplifying LDAP operations, based on the pattern of Spring's JdbcTemplate. The framework relieves the user of common chores, such as looking up and closing contexts, looping through results, encoding/decoding values and filters, and more. The LdapTemplate class encapsulates all the plumbing work involved in traditional LDAP programming, such as creating a DirContext, looping through NamingEnumerations, handling exceptions and cleaning up resources. This leaves the programmer to handle the important stuff - where to find data (DNs and Filters) and what do do with it (map to and from domain objects, bind, modify, unbind, etc.), in the same way that JdbcTemplate relieves the programmer of all but the actual SQL and how the data maps to the domain model. In addition to this, Spring LDAP provides transaction support, a pooling library, exception translation from NamingExceptions to a mirrored unchecked Exception hierarchy, as well as several utilities for working with filters, LDAP paths and Attributes.

This plugin provides support for textlint. <h3>What&rsquo;s the textlint?</h3> <p>See <a href="https://github.com/textlint/textlint">https://github.com/textlint/textlint</a></p> <h3>Usage</h3> <h4>Install textlint and rules</h4> <p>Of course, it assumes that nodejs and npm are installed.</p> <p>e.g.</p> <pre><code>$ mkdir txtlint $ cd txtlint $ npm init $ npm install textlint --save-dev $ npm install textlint-rule-max-ten textlint-rule-spellcheck-tech-word textlint-rule-no-mix-dearu-desumasu --save-dev </code></pre> <h4>Create .textlintrc</h4> <pre><code>$ touch .textlintrc </code></pre> <pre><code class="json">{ &quot;rules&quot;: { &quot;max-ten&quot;: { &quot;max&quot;: 3 }, &quot;spellcheck-tech-word&quot;: true, &quot;no-mix-dearu-desumasu&quot;: true } } </code></pre> <p>You can also set parameters to Options (see below).</p> <h4>Set textlint and .textlintrc paths</h4> <p>Set paths to the Options (see below).</p> <p>e.g.</p> <ul> <li>textlint Path: /path/to/txtlint/node_modules/.bin/textlint (textlint.cmd in Windows)</li> <li>.textlintrc Path: /path/to/textlint/.textlintrc</li> </ul> <h4>Open Action Items window</h4> <ul> <li>Click Window > Action Items.</li> <li>Click &ldquo;Show action items for currently edited file only&rdquo; icon.</li> <li>Open your markdown or text file.</li> </ul> <h3>Options</h3> <p>Tools > Options > Editor > textlint</p> <ul> <li>textlint Path: Absolute path to textlint</li> <li>.textlintrc Path: Absolute path to .textlintrc</li> <li>Options : You can set options for the textlint command</li> <li>Enable in HTML files: To use the html plugin, you can check this</li> <li>Refresh on Save: To scan the document on save, you can check this (Checked by default)</li> <li>Show Annotations: To show annotations in the glyph gutter, you can check this (Checked by default)</li> </ul> <h3>Actions</h3> <h4>Fix</h4> <p>You have to save your file before you run this action.<br/> If there is a fixable rule&rsquo;s error, you can fix it. Right-click an item > Click <code>Fix</code>.<br/> To refresh items, your document is saved once.</p> <h4>Fix All</h4> <p>You have to save your file before you run this action.<br/> If there are fixable rule&rsquo;s errors, you can fix them. Right-click an item > Click <code>Fix All</code>.<br/> This action runs <code>textlint --fix</code> command.</p> <h4>Refresh</h4> <p>You can refresh results forcibly by the following action: Right-click your editor > Click "textlint Refresh".</p> <p>You can also set the shortcut key(Tools > Options > Keymap). </p> <h3>NOTE</h3> <ul> <li>The plugin scans only current file.</li> <li>The plugin does not refresh results automatically. Please save your file or run the refresh action.</li> <li>Use <code>UTF-8</code> as file encoding and <code>LF</code> as line endings.</li> <li>This plugin may not work properly in Windows. (Please try to check above.)</li> <li>If you cannot get expected results, just try to run the <code>textlint</code> commands once in your CLI.</li> </ul>

The OODT grid services (product and profile services) use CORBA or RMI as their underlying network transport. However, limitations of CORBA and RMI make them inappropriate for large-scale deployments. For one, both are procedural mechanisms, providing a remote interface that resembles a method call. This makes streaming of data from a service impossible, because there are limitations to the sizes of data structures that can be passed over a remote method call. Instead, repeated calls must be made to retrieve each block of a product, making transfer speeds horribly slow compared to HTTP or FTP. (Block-based retrieval of profiles was never implemented, resulting in out of memory conditions for large profile results, which is another problem.) Second, both CORBA and RMI rely on a central name registry. The registry makes an object independent of its network location, enabling a client to call it by name (looking up its last known location in the registry). However, this requires that server objects be able to make outbound network calls to the registry (through any outbound firewall), and that the registry accept those registrations (through any inbound firewall). This required administrative action at institutions hosting server objects and at the institution hosting the registry. Often, these firewall exceptions would change without notice as system adminstrators changed at each location (apparently firewall exceptions are poorly documented everywhere). Further, in the two major deployments of OODT (PDS and EDRN), server objects have almost never moved, nullifying any benefit of the registry. This project, OODT Web Grid Services, avoids the prolems of CORBA and RMI by using HTTP as the transport mechanism for products and profiles. Further, it provides a password-protected mechanism to add new sets of product and profile query handlers, enabling seamless activation of additional capabilities.

# 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(); } ```