Java import-mappings require manual modification of pom.xml to compile generated code

[jlar310]

Description

I have a shared Java package that contains the data model classes that will be used by my Spring Boot API server and also by Java clients. I can specify these classes with the importMappings configuration option. However, there is no method I can find where I can add the library that contains those classes as a dependency in the generated pom.xml. The pom file must be modified after generation in order to compile the generated code which references the mapped classes. This presents a problem for automated bulds. Yes it can be scripted, but we're so close to having everything in place.

Or is there some feature that can do this and I just haven't found the right documentation yet?

Swagger-codegen version

Maven plulgin 2.3.0-SNAPSHOT

Swagger declaration file content or url

N/A

Command line used for generation

Steps to reproduce

Related issues/PRs

Suggest a fix/enhancement

Add a configuration option related to importMappings where the user can specify the group/artifact/version to provide the mapped classes and include that dependency in the generated build files

[wing328]

What about using the -t option with customized templates?

[jlar310]

Thanks, I will take a look at that option. However I still can't help but think that the import mappings feature is somewhat incomplete without easy dependency management.

[jlar310]

Making a pom.mustache template does indeed work, but because I must copy the entire pom from swagger-codegen sources, it will require constant maintenance as the swagger codebase evolves. I would still advocate for a more dynamic import-dependency feature. Of course, that still leaves us with configuring repositories for said dependencies as we prefer to include all needed repository information in project poms to reduce the need for external configuration. But it is at least possible to define those outside the project pom, so I think that injecting additional dependency information is still a worthwhile goal.

[jgensler8]

Though not exactly the same issue, our team has used a combination of maven plugins to get a workflow to regenerate files in src/main/java/io/swagger. I figured I would write this here as this is the most relevant issue relating to overwriting a pom.xml file.

Flow is:

1. clean src
2. generate into target
3. copy to src
4. delete from target (to avoid duplicate classes)
5. compilation

I think there are still concerns with changing the swagger.yml template and not compiling before pushing, but this does evade overwriting the pom.xml when using swagger-codegen's plugin to have a configuration of <output>.</output>

# inside <build><plugins>

<plugin>
  <artifactId>maven-clean-plugin</artifactId>
  <executions>
    <execution>
      <id>clean-additional-generated-files</id>
      <phase>initialize</phase>
      <goals>
        <goal>clean</goal>
      </goals>
      <configuration>
        <excludeDefaultDirectories>true</excludeDefaultDirectories>
        <filesets>
          <fileset>
            <directory>src/main/java/io/swagger</directory>
            <followSymlinks>false</followSymlinks>
          </fileset>
        </filesets>
      </configuration>
    </execution>
    <execution>
      <id>clean-target-files</id>
      <phase>process-sources</phase>
      <goals>
        <goal>clean</goal>
      </goals>
      <configuration>
        <excludeDefaultDirectories>true</excludeDefaultDirectories>
        <filesets>
          <fileset>
            <directory>${basedir}/target/generated</directory>
            <followSymlinks>false</followSymlinks>
          </fileset>
        </filesets>
      </configuration>
    </execution>
  </executions>
</plugin>

<plugin>
  <groupId>io.swagger</groupId>
  <artifactId>swagger-codegen-maven-plugin</artifactId>
  <version>2.3.1</version>
  <executions>
    <execution>
      <phase>generate-sources</phase>
      <goals>
        <goal>generate</goal>
      </goals>
      <configuration>
        <inputSpec>swagger.yml</inputSpec>
        <language>spring</language>
        <output>${basedir}/target/generated</output>
      </configuration>
    </execution>
  </executions>
</plugin>

<plugin>
  <artifactId>maven-resources-plugin</artifactId>
  <version>3.0.2</version>
  <executions>
    <execution>
      <id>copy-resources</id>
      <phase>generate-sources</phase>
      <goals>
        <goal>clean</goal>
      </goals>
      <configuration>
        <outputDirectory>${basedir}/src/main/java/io/swagger</outputDirectory>
        <resources>
          <resource>
            <directory>${basedir}/target/generated/src/main/java/io/swagger</directory>
          </resource>
        </resources>
      </configuration>
    </execution>
  </executions>
</plugin>

[silkentrance]

@jgensler8 why would you want to copy the generated sources, why not use the delegate pattern as swagger supports it. That way you just implement the delegate interfaces and register your delegates with swagger, or use spring.

[silkentrance]

@jlar310 don't use the generated pom, use your own. we do this in a project of ours and this works just fine, both with model only packages and with api packages.