swagger-core

swagger-core copied to clipboard

We have a project that implements two different OpenAPI specs and these are done in two separate resource packages. When we run the swagger-maven-plugin we want it to generate two separate spec files, one from each resource package. However the plugin will produce the same spec file, the one for the resource package that is run first.

For example in the example below, the spec files generated all use the resource package "first.resource.package".

<plugin>
	<groupId>io.swagger.core.v3</groupId>
	<artifactId>swagger-maven-plugin</artifactId>
	<version>2.0.5</version>
	<executions>
		<execution>
			<configuration>
				<outputFileName>openapi-1</outputFileName>
				<outputPath>${project.build.directory}/generated-docs</outputPath>
				<outputFormat>JSONANDYAML</outputFormat>
				<openapiFilePath>${project.basedir}/src/main/resources/openapi-info.json</openapiFilePath>
				<resourcePackages>
					<package>first.resource.package</package>
				</resourcePackages>
				<readAllResources>false</readAllResources>
				<prettyPrint>TRUE</prettyPrint>
			</configuration>
			<id>first</id>
			<phase>compile</phase>
			<goals>
				<goal>resolve</goal>
			</goals>
		</execution>
		<execution>
			<configuration>
				<outputFileName>openapi-2</outputFileName>
				<outputPath>${project.build.directory}/generated-docs</outputPath>
				<outputFormat>JSONANDYAML</outputFormat>
				<openapiFilePath>${project.basedir}/src/main/resources/openapi-info.json</openapiFilePath>
				<resourcePackages>
					<package>second.resource.package</package>
				</resourcePackages>
				<readAllResources>false</readAllResources>
				<prettyPrint>TRUE</prettyPrint>
			</configuration>
			<id>second</id>
			<phase>compile</phase>
			<goals>
				<goal>resolve</goal>
			</goals>
		</execution>
	</executions>
</plugin>

Please note that I have tried this in 2.0.6-SNAPSHOT and it produces the same results.

Please try with 2.0.6 version, providing a different contextId param in each execution e.g.

<execution>
 <configuration>
  <outputFileName>openapi-1</outputFileName>
  <contextId>openapi-1</contextId>
...
<execution>
 <configuration>
  <outputFileName>openapi-2</outputFileName>
  <contextId>openapi-2</contextId>
...

The problem seems to persist with version 2.1.13 when specifying a configurationFilePath. The plugin only respects the first configuration-file and uses it for all subsequent executions.

This is the plugin-configuration we use:

<plugin>
	<groupId>io.swagger.core.v3</groupId>
	<artifactId>swagger-maven-plugin</artifactId>
	<version>2.1.13</version>
	<configuration>
		<outputFormat>JSONANDYAML</outputFormat>
		<prettyPrint>TRUE</prettyPrint>
		<outputPath>${project.build.directory}/${project.build.finalName}</outputPath>
		<outputPath>${project.build.directory}/${project.build.finalName}</outputPath>
	</configuration>
	<executions>
		<execution>
			<id>openapi</id>
			<phase>compile</phase>
			<goals>
				<goal>resolve</goal>
			</goals>
			<configuration>
				<outputFileName>openapi</outputFileName>
				<configurationFilePath>${project.build.directory}/openapi-configurationFile.yaml</configurationFilePath>
			</configuration>
		</execution>
		<execution>
			<id>openapi-qs</id>
			<phase>compile</phase>
			<goals>
				<goal>resolve</goal>
			</goals>
			<configuration>
				<outputFileName>openapi-qs</outputFileName>
				<configurationFilePath>${project.build.directory}/openapi-configurationFile-qs.yaml</configurationFilePath>
			</configuration>
		</execution>
		<execution>
			<id>openapi-prod</id>
			<phase>compile</phase>
			<goals>
				<goal>resolve</goal>
			</goals>
			<configuration>
				<outputFileName>openapi-prod</outputFileName>
				<configurationFilePath>${project.build.directory}/openapi-configurationFile-prod.yaml</configurationFilePath>
			</configuration>
		</execution>
	</executions>
</plugin>

@dstango : You haven't added a <contextId> to the configuration-part for each execution, as @frantuma pointed out? The <executionId> for the plugin isn't enough, as it seems that the plugin caches contexts between executions, unless you specify a unique contextId for that configuration.

@mortenberg80 thanks for pointing to the contextId -- I overlooked that part, as I thought the id of the execution would be enough to distinguish. Will try if it helps after returning from vacation :-).