Download JAR files tagged by phase with all dependencies

This is an implementation of syntax highlighting as an extension module for XSLT processors, so if you have e.g. article about programming written in DocBook, code examples can be automatically syntax highlighted during the XSLT processing phase. This version of xslthl provides extensions of the Apache Xalan and Saxon XSLT processors.

This Maven plugin creates in the initialization phase a copy of the original pom where all properties get resolved by its actual values. This substituted POM is used in the further processing. Especially it will be used when an upload to the local or remote repository takes place.

KoPeMe is a framework for enabling performance tests in Java. This makes it possible to live a software development process where performance measures are taken continously and therefore react continously to changes in performance. With continous performance testing, one avoids refactorings after performance problems occured in a big testing phase before releasing the software.

We skip staging of some submodules, but if you skip staging in the last submodule it skips all staging (a serious error in the design of the nexus staging plugin that has been closed "wontfix" - issues.sonatype.org/browse/NEXUS-9138). The backup solution to that problem is to skip the deploy phase in the submodule. We want to deploy the artifact of bedrock-site to AWS, but not publish the war file to nexus. The recommended solution is to add this dummy node at the end of the submodule list.

Babylon is a tool to gather messages, and their translations from property files. It performs a round-trip consisting of two phases: export phase and import phase. In the export phase the messages are written to a Google Sheets spreadsheet. A translator will then fill in the missing translations. In the import phase, the spreadsheet (with the missing translations filled out by a translator) is examined, and the newly translated messages are used to update the respective translation property files. Also, the state of the translation, snapshot, is written out to a disk in the form of JSON file. Babylon can be run as a Maven plugin or as a standalone console application.

Babylon is a tool to gather messages, and their translations from property files. It performs a round-trip consisting of two phases: export phase and import phase. In the export phase the messages are written to a Google Sheets spreadsheet. A translator will then fill in the missing translations. In the import phase, the spreadsheet (with the missing translations filled out by a translator) is examined, and the newly translated messages are used to update the respective translation property files. Also, the state of the translation, snapshot, is written out to a disk in the form of JSON file. Babylon can be run as a Maven plugin or as a standalone console application.

配置监控信息，在web.xml中添加 <filter> <description>拦截获取js与css过滤</description> <filter-name>MergeFilter</filter-name> <filter-class>com.njzxw.filter.MergeFilter</filter-class> <init-param> <!-- js合并输出路径 --> <param-name>jsDir</param-name> <param-value>${js.path}</param-value> </init-param> <init-param> <!-- css合并输出路径 --> <param-name>cssDir</param-name> <param-value>${css.path}</param-value> </init-param> </filter> 同时添加一个合并js\css对应一个merge.xml，最好放置在同级，如： <merge> <group name="sss" > <js path="js/common/common.js" /> <js path="js/common/index.js" /> <css path="css/common/animate.css" /> <css path="css/common/normalize.css" /> </group> </merge> 访问项目：xxx/sss.js xxx/sss.css 同时配合maven插件： compress-maven-plugin结合使用： <plugin> <groupId>com.github.eliayng</groupId> <artifactId>compress-maven-plugin</artifactId> <version>1.0.0</version> <executions> <execution> <phase>compile</phase> <goals> <goal>compress</goal> </goals> </execution> </executions> <configuration> <skip>${skipCompress}</skip> <poolNum>50</poolNum> <jsOutDir>${jsOutDir}</jsOutDir> <cssOutDir>${cssOutDir}</cssOutDir> <!--是否监控编译class文件--> <isCompressClass>true</isCompressClass> <!-- 是否复制资源文件 --> <isResourcesCopy>true</isResourcesCopy> </configuration> </plugin>

Oxalis integration test. Compiles and packages everything, after which the web container is started in the pre-integration-test phase, the .war file is deployed and the tests are executed in the integration-test phase. After the tests have been executed, the web container is stopped in the post-integration-test phase. The reason for using failsafe is the fact that Surefire would fail the build in the integration-test phase, without taking down the server in the post-integration-test phase. This implementation uses Tomcat, but you may change this to your liking. See http://cargo.codehaus.org/Maven2+plugin for more information.

# 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 |