Hey there, let's break down your issues and get those stubs properly packaged and uploaded to Nexus. I've worked through similar setup headaches with older Spring Cloud Contract versions, so let's tackle each problem one by one:

1. Stub JSON Files Not Generating After Adding skip Config #

Setting <spring.cloud.contract.verifier.skip>true</spring.cloud.contract.verifier.skip> completely disables the Contract Verifier plugin—including the step that generates the stub JSON files from your contract definitions. That's why you're not seeing any stubs at all.

Instead of skipping the verifier entirely, you want to keep stub generation enabled but disable the default stub jar creation. Adjust your properties like this:

<properties>
  <!-- Keep stub generation turned on -->
  <spring.cloud.contract.verifier.generateStubs>true</spring.cloud.contract.verifier.generateStubs>
  <!-- Disable the default stub jar packaging from the verifier -->
  <spring.cloud.contract.verifier.stubJar.skip>true</spring.cloud.contract.verifier.stubJar.skip>
</properties>

This way, the plugin will still generate your stub JSONs, but won't create the default jar—leaving you free to build your own with the Assembly plugin.

2. Target Directory Has stub Instead of snippets/stubs (Spring Cloud Contract 1.2.4) #

You're hitting a version-specific path difference. In Spring Cloud Contract 1.x versions (like 1.2.4), the generated stubs are placed directly in target/stubs, not target/snippets/stubs—that path was introduced in 2.x and later.

Update your Assembly plugin's fileSet for stubs to point to the correct directory:

<fileSet>
  <directory>${project.build.directory}/stubs</directory>
  <outputDirectory>META-INF/${project.groupId}/${project.artifactId}/${project.version}/mappings</outputDirectory>
  <includes>
    <include>**/*</include>
  </includes>
</fileSet>

3. Required Files for Stub Runner to Use Your Stub Jar #

Stub Runner needs a specific structure to load and run your stubs correctly. Here's the minimum you need:

• Stub Mapping Files: The JSON files generated from your contracts (these live in META-INF/${groupId}/${artifactId}/${version}/mappings). These define the request/response matching rules for the stub server.
• Model Classes (If Needed): If your contract uses custom POJOs (like your com/example/model classes), include their compiled bytecode (from target/classes) and source code (optional, but helpful for consumers) in the jar so the stub server can serialize/deserialize them correctly.
• Optional: Original Contract Files: Including the .groovy contract files in META-INF/${groupId}/${artifactId}/${version}/contracts is optional, but it helps consumers understand the expected behavior without digging into the JSON stubs.

Adjusted Full Assembly Configuration #

Here's your updated assembly config with the fixes above:

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.3"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.3 http://maven.apache.org/xsd/assembly-1.1.3.xsd">
  <id>stubs</id>
  <formats>
    <format>jar</format>
  </formats>
  <includeBaseDirectory>false</includeBaseDirectory>
  <fileSets>
    <!-- Include model source (optional but helpful for consumers) -->
    <fileSet>
      <directory>src/main/java</directory>
      <outputDirectory>/</outputDirectory>
      <includes>
        <include>**/com/example/model/*.*</include>
      </includes>
    </fileSet>
    <!-- Include compiled model classes -->
    <fileSet>
      <directory>${project.build.directory}/classes</directory>
      <outputDirectory>/</outputDirectory>
      <includes>
        <include>**/com/example/model/*.*</include>
      </includes>
    </fileSet>
    <!-- Corrected stub path for 1.2.4 -->
    <fileSet>
      <directory>${project.build.directory}/stubs</directory>
      <outputDirectory>META-INF/${project.groupId}/${project.artifactId}/${project.version}/mappings</outputDirectory>
      <includes>
        <include>**/*</include>
      </includes>
    </fileSet>
    <!-- Include original contract files -->
    <fileSet>
      <directory>${basedir}/src/test/resources/contracts</directory>
      <outputDirectory>META-INF/${project.groupId}/${project.artifactId}/${project.version}/contracts</outputDirectory>
      <includes>
        <include>**/*.groovy</include>
      </includes>
    </fileSet>
  </fileSets>
</assembly>

Once you make these changes, run mvn clean install—you should see the stub JSONs generated in target/stubs, and your custom stub jar will be built with the correct structure for Nexus. Consumers can then use Stub Runner to pull this jar from Nexus and run integration tests against your service's stubs.

内容的提问来源于stack exchange，提问作者frankskywalker