Out of the box support for swagger-codegen-maven-plugin

There is no support for automatically detecting and adding to the classpath the automatically generated code by the swagger-codegen-maven-plugin.

This means that, even though the project builds without issues from the command line, all the java classes that import the auto-generated code complain that those imports don’t exist from within VSCode.

A work-around is following the same advice you gave for “Annotation Processing support for Maven projects” at: https://github.com/redhat-developer/vscode-java/wiki/Annotation-Processing-support-for-Maven-projects.

i.e. you add the generated source code path with the build-helper-maven-plugin to your pom manually, but this is not ideal.

e.g. assuming <sourceFolder>src/main/java</sourceFolder>

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <version>3.0.0</version>
                <executions>
                    <execution>
                        <!-- Need to ensure the generated source folder is added to the project classpath, in jdt.ls -->
                        <id>add-source</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>add-source</goal>
                        </goals>
                        <configuration>
                            <sources>
                                <source>target/generated-sources/swagger/src/main/java</source>
                            </sources>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

Any chances to get this done automatically? Or at the very least, could you add this to the documentation for others that stumble on the same issue?

Thanks

[testforstephen]

I see. The current m2e leverages lifecycle-mapping-metadata to recognize the customized generate-sources goal from the maven plugin. Here is a wiki about how m2e lookup the lifecycle mapping from different places.

Both antlr4-maven-plugin and jaxb2-maven-plugin provide m2e lifecycle-mapping-metadata in the plugin itself, that’s why vscode-java can handle them well.

• antlr4-maven-plugin/resources/META-INF/m2e/lifecycle-mapping-metadata.xml
• jaxb2-maven-plugin/src/main/resources/META-INF/m2e/lifecycle-mapping-metadata.xml

I summarized the possible solutions for such kind of issue:

• Ask the corresponding maven plugin to provide embedded lifecycle-mapping-metadata.xml.

• Configure the lifecycle-mapping-metadata for the maven plugins you used in your project’s pom.xml directly.

  • Option 1: Add a dedicated <pluginManagement> section to configure m2e lifecycle mapping.

  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>org.eclipse.m2e</groupId>
          <artifactId>lifecycle-mapping</artifactId>
          <version>1.0.0</version>
          <configuration>
            <lifecycleMappingMetadata>
              <pluginExecutions>
                <pluginExecution>
                  <pluginExecutionFilter>
                    <groupId>org.antlr</groupId>
                    <artifactId>antlr3-maven-plugin</artifactId>
                    <versionRange>[3.5.2,)</versionRange>
                    <goals>
                      <goal>antlr</goal>
                    </goals>
                  </pluginExecutionFilter>
                  <action>
                    <execute>
                      <runOnIncremental>true</runOnIncremental>
                      <runOnConfiguration>true</runOnConfiguration>
                    </execute>
                  </action>
                </pluginExecution>
              </pluginExecutions>
            </lifecycleMappingMetadata>
          </configuration>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
  

  • Option 2: Use a simpler syntax to configure m2e lifecycle mapping metadata directly under the execution section of your maven plugin.

  <build>
    <plugins>
      <plugin>
          <groupId>org.antlr</groupId>
          <artifactId>antlr3-maven-plugin</artifactId>
          <version>3.5.2</version>
          <configuration>
            <sourceDirectory>src</sourceDirectory>
            <libDirectory>src/org/stringtemplate/v4/compiler</libDirectory>
            <verbose>true</verbose>
          </configuration>
          <executions>
            <execution>
              <?m2e execute onConfiguration,onIncremental?> // Configure an inline m2e lifecycle mapping metadata.
              <goals>
                <goal>antlr</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
    </plugins>
  </build>
  

• Allow to set a global lifecycle-mapping-metadata.xml per machine, see a sample. This requires vscode-java to expose a new user settings for that. //cc @fbricon

• Use build-helper-maven-plugin mentioned above to explicitly mark as source folder. The downside is that m2e auto build does not automatically generate generate-sources folders, you still need to run mvn cli to generate the classes.

[fbricon]

jdt.ls doesn’t have a mechanism for discovery and installation of remote m2e connectors. And we cannot maintain support for all m2e connectors for every Maven plugin there is. So yes there’s a gap.

I think m2e needs a better, more generic solution for discovering generated source folders