How to run local contracts with Spring Cloud Contract stub runner - spring-cloud-contract

I have defined some Spring Cloud Contracts that I have packaged into a jar using gradle verifierStubsJar. I would like to run the stubs in that jar with the Spring Cloud Contract stub runner jar. I do not want to have to publish the stubs jar to an artifact repository like Artifactory or a local Maven repository. I just want to run the stubs. How do I pass the location of the jar containing my stubs to the stub runner jar?

If you use gradle generateClientStubs:
curl -Lo stub-runner.jar https://search.maven.org/remotecontent?filepath=org/springframework/cloud/spring-cloud-contract-stub-runner-boot/2.2.1.RELEASE/spring-cloud-contract-stub-runner-boot-2.2.1.RELEASE.jar
java -Djava.security-egd=/dev/./urandom -Dstubrunner.repositoryRoot=stubs://file://absolute/path/to/build/stubs -Dstubrunner.ids=com.company-contract:stubs:8081 -Dstubrunner.stubs-mode=REMOTE -jar stub-runner.jar
If you use gradle verifierStubsJar:
curl -Lo stub-runner.jar https://search.maven.org/remotecontent?filepath=org/springframework/cloud/spring-cloud-contract-stub-runner-boot/2.2.1.RELEASE/spring-cloud-contract-stub-runner-boot-2.2.1.RELEASE.jar
java -cp stub-runner.jar:build/libs/my-contract-stubs.jar -Djava.security-egd=/dev/./urandom -Dstubrunner.ids=com.company:my-contract:stubs:8081 -Dstubrunner.stubs-mode=CLASSPATH org.springframework.boot.loader.JarLauncher
Gotchas:
When using gradle generateClientStubs don't forget the leading slash in the absolute URI to your stubs directory. e.g. stubs://file:///User/me/my-contracts-project/build/stubs.
The stub runner starts a server on port 8080, so you must run your stubs on a different port. You can override the port the stub runner starts on with the usual -Dserver.port.

If you read the docs you would find this section https://cloud.spring.io/spring-cloud-contract/reference/html/project-features.html#features-stub-runner-stubs-protocol
Instead of picking the stubs or contract definitions from Artifactory / Nexus or Git, one can just want to point to a location on drive or classpath. This can be especially useful in a multimodule project, where one module wants to reuse stubs or contracts from another module without the need to actually install those in a local maven repository ot commit those changes to Git.
In order to achieve this it’s enough to use the stubs:// protocol when the repository root parameter is set either in Stub Runner or in a Spring Cloud Contract plugin.
In this example the producer project has been successfully built and stubs were generated under the target/stubs folder. As a consumer one can setup the Stub Runner to pick the stubs from that location using the stubs:// protocol.
#AutoConfigureStubRunner(
stubsMode = StubRunnerProperties.StubsMode.REMOTE,
repositoryRoot = "stubs://file://location/to/the/producer/target/stubs/",
ids = "com.example:some-producer")
Contracts and stubs may be stored in a location, where each producer has its own, dedicated folder for contracts and stub mappings. Under that folder each consumer can have its own setup. To make Stub Runner find the dedicated folder from the provided ids one can pass a property stubs.find-producer=true or a system property stubrunner.stubs.find-producer=true .
#AutoConfigureStubRunner(
stubsMode = StubRunnerProperties.StubsMode.REMOTE,
repositoryRoot = "stubs://file://location/to/the/contracts/directory",
ids = "com.example:some-producer",
properties="stubs.find-producer=true")

After a ton of searching and struggling, this is working for me.
Add this to the producer side build.gradle:
configurations {
// create a configuration that other modules can use
contractStubs {
canBeResolved = false
canBeConsumed = true
}
}
artifacts {
// link the stub jar to the configuration
contractStubs(verifierStubsJar)
}
Add this to the consumer side build.gradle:
dependencies {
testImplementation project(path: ':some-path:probucer-dir', configuration: 'contractStubs')
}
For more info see:
https://docs.gradle.org/current/userguide/cross_project_publications.html

Related

Unable to build cordapp with accounts dependencies

I was able to build a cordapp using Accounts by following the steps at https://github.com/corda/accounts.
This cordapp was building and running until 03/16/2020, but since 03/20/2020 I am seeing errors in my CI builds because https://ci-artifactory.corda.r3cev.com/artifactory/corda-lib-dev/com/r3/corda/lib/accounts/accounts-contracts/1.0-RC04/accounts-contracts-1.0-RC04.jar cannot be accessed. I get a 409 response now, how can I resolve this?
{
"errors" : [ {
"status" : 409,
"message" : "The repository 'corda-lib-dev' rejected the resolution of an artifact 'corda-lib-dev:com/r3/corda/lib/accounts/accounts-contracts/1.0-RC04/accounts-contracts-1.0-RC04.jar' due to conflict in the snapshot release handling policy."
} ]
}
My build.gradle has
accounts_release_version = '1.0-RC04'
accounts_release_group = 'com.r3.corda.lib.accounts'
confidential_id_release_group = "com.r3.corda.lib.ci"
confidential_id_release_version = "1.0-RC03"
repositories {
maven { url 'http://ci-artifactory.corda.r3cev.com/artifactory/corda-lib-dev' }
maven { url 'http://ci-artifactory.corda.r3cev.com/artifactory/corda-lib' }
}
My local builds on my development environment work fine, I assume because I already have the jars in my .m2
Artifactory configuration has been changed to enforce separation between release and snapshot repositories. corda-lib-dev is a snapshot repo and CorDapp developers should not be developing against these.
Releases and release candidates will be available in corda-lib going forward.
Kindly use corda-lib, and develop again release 1.0.
The pom file with RC04 is set to return 409. I assume Corda's way to disallow use of RC04. May be RC03 is also the same. I just tried this today and saw the repository pom files.
Use "1.0" instead of "1.0-RC03"

Vaadin Flow 14, Jetty embedded and static files

I'm trying to create app based on Jetty 9.4.20 (embedded) and Vaadin Flow 14.0.12.
It based on very nice project vaadin14-embedded-jetty.
I want to package app with one main-jar and all dependency libs must be in folder 'libs' near main-jar.
I remove maven-assembly-plugin, instead use maven-dependency-plugin and maven-jar-plugin. In maven-dependency-plugin i add section <execution>get-dependencies</execution> where i unpack directories META-INF/resources/,META-INF/services/ from Vaadin Flow libs to the result JAR.
In this case app work fine. But if i comment section <execution>get-dependencies</execution> then result package didn't contain that directories and app didn't work.
It just cannot give some static files from Vaadin Flow libs.
This error occurs only if i launch packaged app with ...
$ java -jar vaadin14-embedded-jetty-1.0-SNAPSHOT.jar
... but from Intellij Idea it launch correctly.
There was an opinion that is Jetty staring with wrong ClassLoader and cannot maintain requests to static files in Jar-libs.
The META-INF/services/ files MUST be maintained from the Jetty libs.
That's important for Jetty to use java.util.ServiceLoader.
If you are merging contents of JAR files into a single JAR file, that's called a "uber jar".
There are many techniques to do this, but if you are using maven-assembly-plugin or maven-dependency-plugin to build this "uber jar" then you will not be merging critical files that have the same name across multiple JAR files.
Consider using maven-shade-plugin and it's associated Resource Transformers to properly merge these files.
http://maven.apache.org/plugins/maven-shade-plugin/
http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html
The ServicesResourceTransformer is the one that merges META-INF/services/ files, use it.
As for static content, that works fine, but you have to setup your Base Resource properly.
Looking at your source, you do the following ...
final URI webRootUri = ManualJetty.class.getResource("/webapp/").toURI();
final WebAppContext context = new WebAppContext();
context.setBaseResource(Resource.newResource(webRootUri));
That won't work reliably in 100% of cases (as you have noticed when running in the IDE vs command line).
The Class.getResource(String) is only reliable if you lookup a file (not a directory).
Consider that the Jetty Project Embedded Cookbook recipes have techniques for this.
See:
WebAppContextFromClasspath.java
ResourceHandlerFromClasspath.java
DefaultServletFileServer.java
DefaultServletMultipleBases.java
XmlEnhancedServer.java
MultipartMimeUploadExample.java
Example:
// Figure out what path to serve content from
ClassLoader cl = ManualJetty.class.getClassLoader();
// We look for a file, as ClassLoader.getResource() is not
// designed to look for directories (we resolve the directory later)
URL f = cl.getResource("webapp/index.html");
if (f == null)
{
throw new RuntimeException("Unable to find resource directory");
}
// Resolve file to directory
URI webRootUri = f.toURI().resolve("./").normalize();
System.err.println("WebRoot is " + webRootUri);
WebAppContext context = new WebAppContext();
context.setBaseResource(Resource.newResource(webRootUri));

built.sbt without .repositories file with m2compatible set to true

i am in a scenario that the artifacts are published to a local maven repository with both both pom file and ivy file. I am trying to access this repository by treating it as an ivy repo, as a result, I had to set m2compatible=true so that the resolvers can correctly identify the path pattern.
sbt allows one to override the default list of resolvers through the following properties:
-Dsbt.override.build.repos=true -Dsbt.repository.config=<path to sbt repository file>
The foramt of the repository file is something like the following,
[repositories]
local
my-artifacts: http://my.artifact.proxyserver.com/artifacts/,[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]
maven : http://my.artifact.proxyserver.com/artifactory/maven-central
My question is how am I able to specify m2compatible=true for the resolver "my-artifacts" in the above file? Because without that setting, if I depend on
com.google.common % guava % 23.1
the resolver will look for the path:
com.google.common/guava/23.1
instead of
com/google/common/guava/23.1
sbt allows to add mavenCompatible towards the end of an ivy resolver.

Can't understand gradle jar task code that creates executable fat-jar

I am learning Gradle but I don't understand the jar task code that creates a jar with all the dependencies inside ( taken from Gradle Cookbook ):
jar {
baseName = jarBaseName
manifest { attributes "Main-Class": mainClass }
from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
}
My questions are:
1.The task name is jar. Because it's not written like jar<<{...} I'm assuming that this is run in the configuration phase, and not the execution one. Am I correct?
2.What exactly is configurations.compile? I'm assuming that some kind of dependencies classpath is queried, and each jar is zipTree-ed. Then all of this stuff is merged with the base classpath
. Please elaborate about it
3.The zipTree method, I'm assuming it kind of unarchives each jar but I'm not sure. Am I correct?
Regards,
Yes You're correct. When no action added (mostly with << see docs) the code is run at configuration phase. The code You provided is also run at configuration phase.
configurations.compile refers to a configuration named compile using configurations object (a kind of a configurations container). Prior to gradle 2.0 compile configuration is provided by default with java plugin. AFAIR now it's called javaCompile. According to zipTree You're also correct.
Yes You're.

seam solder (former weld-extensions project) is not initialized

I want to use logger in my java web application.
I'm using JBossAS 6.0.0.final, cdi (weld), jsf ... etc. Seam solder proposes to use an abstract logger is not tying to a concrete implementation (slf4j, log4j, etc) using jboss-logging api.
In order to get this logger in your code will need to write
# Inject
org.jboss.logging.Logger log
seam-solder.jar has the producer for this logger.
package org.jboss.seam.solder.log;
...
class LoggerProducers
{
# Produces
org.jboss.logging.Logger produceLog (InjectionPoint injectionPoint) {}
}
When I deploying my application, I get an error
15:51:18,300 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs:///C:/Java/jboss-6.0.0.Final/server/default/deploy/kamis-web-client.5.0.0-SNAPSHOT.ear_WeldBootstrapBean state=Create: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Logger] with qualifiers [#Default] at injection point [[field] #Inject private ru.kamis.suite.webclient.web.breadcrumbs.BreadcrumbsManager.log]
This is due to the seam-solder.jar has not META-INF/beans.xml file, and it is necessary for cdi container.
If to add beans.xml file in seam-solder.jar manually, then the application works WELL.
How to do without hacks?
To build my application I use maven, so my solution is not comfortable and NOT fine.
PS: Former weld-extensions project contained META-INF/beans.xml file in jar.
with seam-solder-3.0.0.Beta1 there should be no need to modify the jar

Resources