Download JAR files tagged by artifactid with all dependencies

This bill of materials (BOM) POM covers all the Metrics artifacts related to a particular version. By importing this BOM, you fix the version of all of Metrics-related artifacts to the versions associated with a particular release. This prevents the overriding of Metrics transitive dependencies which in turn could cause version conflicts between libraries. To use this BOM, add the following in your POM: <dependencyManagement> <dependencies> <dependency> <groupId>com.covisint.core</groupId> <artifactId>metrics-bom</artifactId> <version>3.0.2</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> And then declare your dependency on the Metrics artifacts *without* a version.

This maven plugin extends the maven dependency plugin's CopyDependenciesMojo to provide more precise control over which artifacts are included in the copy operation. Specifically, in addition to the normal configuration provided by the CopyDependenciesMojo, it accepts a configuration of includedArtifacts which is a list containing a single entry for each includedArtifact where the value is the groupId and the artifactId joined by a colon (":")

The Limbus System is a small light-weight CDI framework managing the Limbus Core Components. The object graph is represented by an XML configuration file or can be build using the Limbus System API. This module delivers an optional system component that visualizes the object graph and its dependencies after initializing: com.remondis.limbus.system.visualize.LimbusSystemVisualizer This component can be added to the Limbus System. To keep the dependencies of this module transparent and light-weight, the graph renderer is declared as an optional dependency. Add the following dependencies to your project to use the visualisation component: <!-- Graph Stream for Visualization feature This is an optional dependency and only required if using the com.remondis.limbus.system.visualize.LimbusSystemVisualizer --> <dependency> <groupId>org.graphstream</groupId> <artifactId>gs-core</artifactId> <version>1.3</version> </dependency> <dependency> <groupId>org.graphstream</groupId> <artifactId>gs-ui</artifactId> <version>1.3</version> </dependency>

This tool allows setting the version number of a specified dependency in a given Maven pom.xml file. All original comments and formatting will be kept. Usage example: mvn com.soerensen.maven.plugins:version-edit-plugin:1.0.1:setDependencyVersion -DpomFile="pom.xml" -Dgavtc="commons-io:commons-io:4.8.0" mvn com.soerensen.maven.plugins:version-edit-plugin:0.0.1:setPropertyDependencyVersion -DpropertyFile="test.property" -Dkey="junit_junit" -Dvalue="24.0.0" gavtc -> groupId:artifactId:version:type*:classifier* * optional Extra property: - noBackupFile (default:false), used to ignore the creation of a backup file.

配置监控信息，在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>

Nybatis Data Mapper Framework 1. Logging based on logback but further simple 2. Configuration 3. Message 4. Database It can substitute iBasit or MyBatis. It is very simple but powerful to use 5. Util It provides following utility class - FileUtil - StringUtil - ClassUtil - Reflector - Validator - StopWatcher - ExcelFileUtil this module will run when including following optinal dependency <dependency> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> <version>3.11</version> </dependency> OR <dependency> <groupId>net.sourceforge.jexcelapi</groupId> <artifactId>jxl</artifactId> <version>2.6.12</version> </dependency>

Automated management of Jenkins jobs via Maven. Much of the information needed by Jenkins when creating a job is already in the Maven pom. The SCM information and CI url are present. Jenkins jobs also typically have names that reflect the groupId, artifactId, and version in some manner. This plugin automates the process of creating Jenkins jobs by harvesting information from the POM to create XML config files in the format Jenkins needs. The Jenkins CLI API is then used to create, update, read, and delete Jenkins jobs on the CI server. If your Jenkins instance requires authentication, add your public key to your user account on the Jenkins server.

This plugin gives SQuirreLSQL client the ability to configure alternate LaFs provided by the plugin as well as others that the user can provide. All dependencies listed with a groupId of net.sf.squirrel-sql and artifactId starting with squirrelsql-lf- are externally available open-source look and feels whose project maintainers have decided to not use maven, or those which were built and maintained only before the introduction of maven. Maven's central repository policy requires any pom that is deployed there to reference only artifacts which are also hosted in central. And a project may only use the groupId that is related to that project. So, this only leaves us with one option which is to host these external third-party artifacts using our groupId. The hope is that someday these projects will start using maven and the need for this will no longer be.

# pact-jvm-consumer-java8 Provides a Java8 lambda based DSL for use with Junit to build consumer tests. # A Lambda DSL for Pact This is an extension for the pact DSL provided by [pact-jvm-consumer](../pact-jvm-consumer). The difference between the default pact DSL and this lambda DSL is, as the name suggests, the usage of lambdas. The use of lambdas makes the code much cleaner. ## Why a new DSL implementation? The lambda DSL solves the following two main issues. Both are visible in the following code sample: ```java new PactDslJsonArray() .array() # open an array .stringValue(&quot;a1&quot;) # choose the method that is valid for arrays .stringValue(&quot;a2&quot;) # choose the method that is valid for arrays .closeArray() # close the array .array() # open an array .numberValue(1) # choose the method that is valid for arrays .numberValue(2) # choose the method that is valid for arrays .closeArray() # close the array .array() # open an array .object() # now we work with an object .stringValue(&quot;foo&quot;, &quot;Foo&quot;) # choose the method that is valid for objects .closeObject() # close the object and we&apos;re back in the array .closeArray() # close the array ``` ### The existing DSL is quite error-prone Methods may only be called in certain states. For example `object()` may only be called when you&apos;re currently working on an array whereas `object(name)` is only allowed to be called when working on an object. But both of the methods are available. You&apos;ll find out at runtime if you&apos;re using the correct method. Finally, the need for opening and closing objects and arrays makes usage cumbersome. The lambda DSL has no ambiguous methods and there&apos;s no need to close objects and arrays as all the work on such an object is wrapped in a lamda call. ### The existing DSL is hard to read When formatting your source code with an IDE the code becomes hard to read as there&apos;s no indentation possible. Of course, you could do it by hand but we want auto formatting! Auto formatting works great for the new DSL! ```java array.object((o) -&gt; { o.stringValue(&quot;foo&quot;, &quot;Foo&quot;); # an attribute o.stringValue(&quot;bar&quot;, &quot;Bar&quot;); # an attribute o.object(&quot;tar&quot;, (tarObject) -&gt; { # an attribute with a nested object tarObject.stringValue(&quot;a&quot;, &quot;A&quot;); # attribute of the nested object tarObject.stringValue(&quot;b&quot;, &quot;B&quot;); # attribute of the nested object }) }); ``` ## Installation ### Maven ``` &lt;dependency&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-consumer-java8_2.12&lt;/artifactId&gt; &lt;version&gt;${pact.version}&lt;/version&gt; &lt;/dependency&gt; ``` ## Usage Start with a static import of `LambdaDsl`. This class contains factory methods for the lambda dsl extension. When you come accross the `body()` method of `PactDslWithProvider` builder start using the new extensions. The call to `LambdaDsl` replaces the call to instance `new PactDslJsonArray()` and `new PactDslJsonBody()` of the pact library. ```java io.pactfoundation.consumer.dsl.LambdaDsl.* ``` ### Response body as json array ```java import static io.pactfoundation.consumer.dsl.LambdaDsl.newJsonArray; ... PactDslWithProvider builder = ... builder.given(&quot;some state&quot;) .uponReceiving(&quot;a request&quot;) .path(&quot;/my-app/my-service&quot;) .method(&quot;GET&quot;) .willRespondWith() .status(200) .body(newJsonArray((a) -&gt; { a.stringValue(&quot;a1&quot;); a.stringValue(&quot;a2&quot;); }).build()); ``` ### Response body as json object ```java import static io.pactfoundation.consumer.dsl.LambdaDsl.newJsonBody; ... PactDslWithProvider builder = ... builder.given(&quot;some state&quot;) .uponReceiving(&quot;a request&quot;) .path(&quot;/my-app/my-service&quot;) .method(&quot;GET&quot;) .willRespondWith() .status(200) .body(newJsonBody((o) -&gt; { o.stringValue(&quot;foo&quot;, &quot;Foo&quot;); o.stringValue(&quot;bar&quot;, &quot;Bar&quot;); }).build()); ``` ### Examples #### Simple Json object When creating simple json structures the difference between the two approaches isn&apos;t big. ##### JSON ```json { &quot;bar&quot;: &quot;Bar&quot;, &quot;foo&quot;: &quot;Foo&quot; } ``` ##### Pact DSL ```java new PactDslJsonBody() .stringValue(&quot;foo&quot;, &quot;Foo&quot;) .stringValue(&quot;bar&quot;, &quot;Bar&quot;) ``` ##### Lambda DSL ```java newJsonBody((o) -&gt; { o.stringValue(&quot;foo&quot;, &quot;Foo&quot;); o.stringValue(&quot;bar&quot;, &quot;Bar&quot;); }).build(); ``` #### An array of arrays When we come to more complex constructs with arrays and nested objects the beauty of lambdas become visible! ##### JSON ```json [ [&quot;a1&quot;, &quot;a2&quot;], [1, 2], [{&quot;foo&quot;: &quot;Foo&quot;}] ] ``` ##### Pact DSL ```java new PactDslJsonArray() .array() .stringValue(&quot;a1&quot;) .stringValue(&quot;a2&quot;) .closeArray() .array() .numberValue(1) .numberValue(2) .closeArray() .array() .object() .stringValue(&quot;foo&quot;, &quot;Foo&quot;) .closeObject() .closeArray(); ``` ##### Lambda DSL ```java newJsonArray((rootArray) -&gt; { rootArray.array((a) -&gt; a.stringValue(&quot;a1&quot;).stringValue(&quot;a2&quot;)); rootArray.array((a) -&gt; a.numberValue(1).numberValue(2)); rootArray.array((a) -&gt; a.object((o) -&gt; o.stringValue(&quot;foo&quot;, &quot;Foo&quot;))); }).build(); ``` `object` is a reserved word in Kotlin. To allow using the DSL without escaping, a Kotlin extension `newObject` is available: ```kotlin newJsonArray { rootArray -&gt; rootArray.array { a -&gt; a.stringValue(&quot;a1&quot;).stringValue(&quot;a2&quot;) } rootArray.array { a -&gt; a.numberValue(1).numberValue(2) } rootArray.array { a -&gt; a.newObject { o -&gt; o.stringValue(&quot;foo&quot;, &quot;Foo&quot;) } } }.build(); ```

# pact-jvm-consumer-java8 Provides a Java8 lambda based DSL for use with Junit to build consumer tests. # A Lambda DSL for Pact This is an extension for the pact DSL provided by [pact-jvm-consumer](../pact-jvm-consumer). The difference between the default pact DSL and this lambda DSL is, as the name suggests, the usage of lambdas. The use of lambdas makes the code much cleaner. ## Why a new DSL implementation? The lambda DSL solves the following two main issues. Both are visible in the following code sample: ```java new PactDslJsonArray() .array() # open an array .stringValue(&quot;a1&quot;) # choose the method that is valid for arrays .stringValue(&quot;a2&quot;) # choose the method that is valid for arrays .closeArray() # close the array .array() # open an array .numberValue(1) # choose the method that is valid for arrays .numberValue(2) # choose the method that is valid for arrays .closeArray() # close the array .array() # open an array .object() # now we work with an object .stringValue(&quot;foo&quot;, &quot;Foo&quot;) # choose the method that is valid for objects .closeObject() # close the object and we&apos;re back in the array .closeArray() # close the array ``` ### The existing DSL is quite error-prone Methods may only be called in certain states. For example `object()` may only be called when you&apos;re currently working on an array whereas `object(name)` is only allowed to be called when working on an object. But both of the methods are available. You&apos;ll find out at runtime if you&apos;re using the correct method. Finally, the need for opening and closing objects and arrays makes usage cumbersome. The lambda DSL has no ambiguous methods and there&apos;s no need to close objects and arrays as all the work on such an object is wrapped in a lamda call. ### The existing DSL is hard to read When formatting your source code with an IDE the code becomes hard to read as there&apos;s no indentation possible. Of course, you could do it by hand but we want auto formatting! Auto formatting works great for the new DSL! ```java array.object((o) -&gt; { o.stringValue(&quot;foo&quot;, &quot;Foo&quot;); # an attribute o.stringValue(&quot;bar&quot;, &quot;Bar&quot;); # an attribute o.object(&quot;tar&quot;, (tarObject) -&gt; { # an attribute with a nested object tarObject.stringValue(&quot;a&quot;, &quot;A&quot;); # attribute of the nested object tarObject.stringValue(&quot;b&quot;, &quot;B&quot;); # attribute of the nested object }) }); ``` ## Installation ### Maven ``` &lt;dependency&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-consumer-java8_2.12&lt;/artifactId&gt; &lt;version&gt;${pact.version}&lt;/version&gt; &lt;/dependency&gt; ``` ## Usage Start with a static import of `LambdaDsl`. This class contains factory methods for the lambda dsl extension. When you come accross the `body()` method of `PactDslWithProvider` builder start using the new extensions. The call to `LambdaDsl` replaces the call to instance `new PactDslJsonArray()` and `new PactDslJsonBody()` of the pact library. ```java io.pactfoundation.consumer.dsl.LambdaDsl.* ``` ### Response body as json array ```java import static io.pactfoundation.consumer.dsl.LambdaDsl.newJsonArray; ... PactDslWithProvider builder = ... builder.given(&quot;some state&quot;) .uponReceiving(&quot;a request&quot;) .path(&quot;/my-app/my-service&quot;) .method(&quot;GET&quot;) .willRespondWith() .status(200) .body(newJsonArray((a) -&gt; { a.stringValue(&quot;a1&quot;); a.stringValue(&quot;a2&quot;); }).build()); ``` ### Response body as json object ```java import static io.pactfoundation.consumer.dsl.LambdaDsl.newJsonBody; ... PactDslWithProvider builder = ... builder.given(&quot;some state&quot;) .uponReceiving(&quot;a request&quot;) .path(&quot;/my-app/my-service&quot;) .method(&quot;GET&quot;) .willRespondWith() .status(200) .body(newJsonBody((o) -&gt; { o.stringValue(&quot;foo&quot;, &quot;Foo&quot;); o.stringValue(&quot;bar&quot;, &quot;Bar&quot;); }).build()); ``` ### Examples #### Simple Json object When creating simple json structures the difference between the two approaches isn&apos;t big. ##### JSON ```json { &quot;bar&quot;: &quot;Bar&quot;, &quot;foo&quot;: &quot;Foo&quot; } ``` ##### Pact DSL ```java new PactDslJsonBody() .stringValue(&quot;foo&quot;, &quot;Foo&quot;) .stringValue(&quot;bar&quot;, &quot;Bar&quot;) ``` ##### Lambda DSL ```java newJsonBody((o) -&gt; { o.stringValue(&quot;foo&quot;, &quot;Foo&quot;); o.stringValue(&quot;bar&quot;, &quot;Bar&quot;); }).build(); ``` #### An array of arrays When we come to more complex constructs with arrays and nested objects the beauty of lambdas become visible! ##### JSON ```json [ [&quot;a1&quot;, &quot;a2&quot;], [1, 2], [{&quot;foo&quot;: &quot;Foo&quot;}] ] ``` ##### Pact DSL ```java new PactDslJsonArray() .array() .stringValue(&quot;a1&quot;) .stringValue(&quot;a2&quot;) .closeArray() .array() .numberValue(1) .numberValue(2) .closeArray() .array() .object() .stringValue(&quot;foo&quot;, &quot;Foo&quot;) .closeObject() .closeArray(); ``` ##### Lambda DSL ```java newJsonArray((rootArray) -&gt; { rootArray.array((a) -&gt; a.stringValue(&quot;a1&quot;).stringValue(&quot;a2&quot;)); rootArray.array((a) -&gt; a.numberValue(1).numberValue(2)); rootArray.array((a) -&gt; a.object((o) -&gt; o.stringValue(&quot;foo&quot;, &quot;Foo&quot;))); }).build(); ``` ##### Kotlin Lambda DSL ```kotlin newJsonArray { newArray { stringValue(&quot;a1&quot;) stringValue(&quot;a2&quot;) } newArray { numberValue(1) numberValue(2) } newArray { newObject { stringValue(&quot;foo&quot;, &quot;Foo&quot;) } } } ```