I Created a sperate repository to store the contract as descibed in this link:
https://github.com/spring-cloud/spring-cloud-contract/tree/main/samples/standalone/contracts
In the producer side, I added the generated jar of contract as follow:
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
<configuration>
<contractsMode>LOCAL</contractsMode>
<contractDependency>
<groupId>com.example.standalone</groupId>
<artifactId>contracts</artifactId>
</contractDependency>
</configuration>
</plugin>
When I execute the maven install, this doesn't generate the contracts verifier classes in the target folder. any help?
Thanks
Please check the sample in spring-cloud-contract-samples repo producer with external contracts
The beer contracts folder contains only contract definitions - it will not generate any test classes.
This project producer with external contracts will generate test classes from the contracts defined in this beer contracts folder.
Related
Currently we have a github repo where we store all the contracts, another repo which contains the producer code, and last but not least another one which contains the consumer code.
On the consumer side working with branches when pointing to the contract repo is well supported by using properties like stubrunner.properties.git.branch (more info can be found here https://cloud.spring.io/spring-cloud-contract/reference/html/appendix.html#additional-application-properties)
But on the producer I can not see any way of using the contracts of a concrete branch, we just can point to the github repo where contracts are stored by using contractsRepositoryUrl of the spring-cloud-contract-maven-plugin
This will be very useful to create a flow of contract testing :
a PR to contract testing repo with the proposal
which will trigger the producer job (passing the pr branch name)
if the repo with the contracts contains the bindings, populated by the producer(previous step), then we could trigger the consumer job and validate if everything is fine with these proposed changes
once the 2 builds are green (producer and consumer) we can merge the changes on the contracts repo
UPDATE : the following spring-cloud-contract-maven-plugin config worked for me, also you can set this property through command line like this -Dstubrunner.properties.git.branch=other_branch_than_master
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
<version>${spring-cloud-contract.version}</version>
<extensions>true</extensions>
<configuration>
<baseClassMappings>
<baseClassMapping>
<contractPackageRegex>.*rest.*</contractPackageRegex>
<baseClassFQN>com.xxx.yyy.contract.ContentCheckBaseTestClass</baseClassFQN>
</baseClassMapping>
</baseClassMappings>
<basePackageForTests>com.xxx.yyy.contract</basePackageForTests>
<contractsRepositoryUrl>git://https://github.com/xxx/yyy.git</contractsRepositoryUrl>
<contractsRepositoryUsername>${GITHUB_USER}</contractsRepositoryUsername>
<contractsRepositoryPassword>${GITHUB_TOKEN}</contractsRepositoryPassword>
<contractsMode>REMOTE</contractsMode>
<testMode>EXPLICIT</testMode>
<testFramework>JUNIT5</testFramework>
<contractsProperties>
<git.branch>another_branch</git.branch>
</contractsProperties>
<contractDependency>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
</contractDependency>
</configuration>
<executions>
<execution>
<phase>deploy</phase>
<goals>
<goal>pushStubsToScm</goal>
</goals>
</execution>
</executions>
</plugin>
You can reuse the same properties presented here (https://docs.spring.io/spring-cloud-contract/docs/2.2.6.RELEASE/reference/html/appendix.html#additional-application-properties) under the e.g. Spring Cloud Contract Maven's <configuration><contractProperties> section. That way you can pick which branch should be downloaded
I have established Spring cloud contract between two microservices in my project successfully. Everything was good until yesterday.
On consumer side, I am referencing the latest version of stubs like below:
#AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})
But this causes problem in some cases where the producer side reverted their latest version and switched back to previous version.
Or
somehow there is a situation that the jar that contains current stubs has a lower version than the latest version in maven repo.
Is there a way in Spring cloud contract to do either one of the following?
1) configure the consumer side to pick up the current project version (referring to project version in pom.xml) instead of the latest version from maven repo?
Or
2) configure the producer side to have a static version of stubs jar but keep dynamic version of other project jars. This would allow the consumer side to refer to the same static version of stubs jar
I read the documentation https://cloud.spring.io/spring-cloud-static/spring-cloud-contract/2.1.1.RELEASE/single/spring-cloud-contract.html#_jar_versioning but it did not help
You can play around with the provided version. We give + to always download the latest. You can set a concrete value e.g. 2.1.1.RELEASE. You can also set ranges. All in all we're using Ivy underneath so you can check out the rules of Ivy http://ant.apache.org/ivy/history/latest-milestone/settings/version-matchers.html
1) configure the consumer side to pick up the current project version instead of the latest one?
What does current mean? Is it the latest? Latest release? If it's the latest release pick + but point to the repo that contains release versions only without snapshots.
I read the documentation https://cloud.spring.io/spring-cloud-static/spring-cloud-contract/2.1.1.RELEASE/single/spring-cloud-contract.html#_jar_versioning but it did not help
What is missing in this section? You asked about static stubs, we describe it there too #AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:2.1.1:stubs:8080"}).
Following worked (for maven project).
Step1: Instead of specifying the ids in #AutoConfigureStubRunner, we can provide it inside application.properties file like below (notice #project.version#, this refers to maven project version )
stubrunner.ids=com.example:http-server-dsl:#project.version#:stubs:8080
Step2: To be able to use #project.version# in properties file, add the following in build section of pom.xml:
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
And in plugins section:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>${mvn-resources-plugin.version}</version>
<configuration>
<delimiters>
<delimiter>#</delimiter>
</delimiters>
<useDefaultDelimiters>false</useDefaultDelimiters>
</configuration>
</plugin>
I am using JUnit for generating Pacts and Pacts maven plugin to post the pact into pact broker.
I am using below plugin Configuration
<plugin>
<groupId>au.com.dius</groupId>
<artifactId>pact-jvm-provider-maven_2.11</artifactId>
<version>3.3.9</version>
<configuration>
<projectVersion>2.0</projectVersion>
<pactBrokerUrl>https:example.com</pactBrokerUrl>
<pactBrokerUsername>username1</pactBrokerUsername>
<pactBrokerPassword>password1</pactBrokerPassword>
<trimSnapshot>true</trimSnapshot> <!-- Defaults to false -->
</configuration>
</plugin>
While Consumenr pact is getting uploaded in broker, I am able to see only single entry of consumer pact of version 2.0. Eirlier I have uploaded version 1.0 eirlier, which is not present in the UI. Is there any way to see the multiple version of same provider pact in HAL browser and get different version of PACTS by Https GET request? Currently I am getting only latest consumenr pact version by http://your-pact-broker/pacts/provider/PROVIDER/consumer/CONSUMER/latest
Please provide some info regurding this and let me know if you need any informaiton.
http://your-pact-broker/pacts/provider/PROVIDER/consumer/CONSUMER/versions will show you all the versions of the pact. You can retrieve a pact using the same URL that you used to PUT it to the broker eg. http://your-pact-broker/pacts/provider/PROVIDER/consumer/CONSUMER/version/CONSUMER_VERSION.
You can explore the Pact Broker API using the embedded HAL browser, by clicking the 'HAL browser' link from the index page of the broker.
Commonly known, that for usage of different jars we need add them to SoapUI/../ext/ directory. for example, for correct work of jdbc requests with IBM/..AS400JDBC Driver we need to add jt400.jar to /ext dir.
But I have problem: my client implements new policy - direct forbidding of using any jars locally, only as dependencies like
<dependency>
<groupId>net.sf.jt400</groupId>
<artifactId>jt400-full</artifactId>
<version>6.0</version>
</dependency>
I successfully uses it in my POM's for CI, but I also need to run my projects in SOAPUI.
So, question is: is there any way to add dependency for external jars, - exists in SoapUI preferences somewhere/somehow? Goal is to remove all jars from soapui/../ext and somehow add dependencies on official.
Sincerely,
Dmitry.
I have thought about this some more: You should be able to roll your own soapui.bat, based on the provided one.
Copy the provided soapui.bat to your desktop.
Modify the variable SOAPUI_HOME to point to your install.
Modify the variable CLASSPATH to include your jars.
Run the modified soapui.bat.
I'm deploying an ear with an EJB onto glassfish 3.1 which I want to call using the appclient script.
The EJB has a method with as parameter a model object which is defined in a separate library.
If I want to use the appclient script I have a Main class with a main method which calls the EJB.
This is also put into a separate jar which is also deployed onto glassfish.
As the model object is located in a separate library I need it in the client jar but also in the EJB.
So I need to reference it somehow in the client jar.
The client jar is a jar (duh) so I cannot add other jars. The Java EE 6 docs say that I should create an ear with the libs but if I do that it doesn't deploy because an ear needs at least an ejb or web module and my client lib has neither.
The solution I found is using the assembly plugin/jar-with-dependencies. This plugin creates a new jar which contains all classes of all dependencies.
This solution works but I'm wondering if this is the way to go or I'm missing something obvious because I cannot imagine this is required. EJB's usually have model objects as parameters so this situation will happen a lot.
So my question is: is there a way to tell glassfish to reference the shared libraries between the app client jar and the ejb jar.
The way I do this is like this:
Separate Maven project with the model. In my case that's a bunch of simple POJOs with JPA and JAX-B annotations, some constants, etc. In Maven, I define this as an OSGi bundle, by specifying <packaging>bundle</packaging>. I call this project MyAppInterface.
Separate Maven projects for other elements that need to deal with the model. In my case, I have one Java EE application with EJBs, Database facade, REST servlet; I have an Integration-Test project which only does tests; a GWT application; etc... In those projects I specify the dependency to the model:
<dependency>
<groupId>com.skalio</groupId>
<artifactId>MyAppInterface</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
When deploying MyAppInterface to Glassfish, I use the following syntax:
asadmin deploy --type osgi --name MyAppInterface /path/to/MyAppInterface-1.0-SNAPSHOT.jar
I understand it that this is placing the model on the classpath of Glassfish, similar to a mysql-connector, only OSGi-style.
I let all these projects be built by a central jenkins CI server, which deploys the artifacts to our internal maven repository. We then add the internal repository in pom.xml of each project. As a result, everyone automatically works with the latest stable MyAppInterface, even if they don't have the code checked out in NetBeans / Eclipse.
Let me know if you need more examples.