How to handle extra classpath from generated code

I'm using Google's AutoValue and Protocol Buffer, both which generate source code under build/generated/source/.... However, each time I start vscode, this java plugin would automatically create a new .classpath file that overrides my manual edit.

Is the plugin going to handle the generated source code? Is there a workaround for now? Thanks.

Are you using Maven or Gradle?
With Maven, if you configure build-helper-maven-plugin, vscode-java 0.1.0 should setup the classpath accordingly.

Could you please attach a sample project?

@minkyn

@minkyn ping. See previous comment

@minkyn

That seems like a duplicate of #285. @minkyn are you using gradle?

I have the same problem when using Maven to generate protocol buffer sources.

Source files are generated like so in the pom:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>3.0.1</version>
    <executions>
        <execution>
            <id>unpack-proto-dependencies</id>
            <phase>generate-sources</phase>
            <goals>
                <goal>unpack-dependencies</goal>
            </goals>
            <configuration>
                <includeArtifactIds>artifact-name-here</includeArtifactIds>
                <excludeTransitive>true</excludeTransitive>
                <overWrite>true</overWrite>
                <outputDirectory>${project.build.directory}/generated-sources/proto</outputDirectory>                            
                <overWriteReleases>true</overWriteReleases>
                <overWriteSnapshots>true</overWriteSnapshots>
            </configuration>
        </execution>
    </executions>
</plugin>

we event try to add it to the test class path like so (not needed for mvn install to work).

<plugin>
    <!-- a hint for IDE's to add the java sources to the classpath -->
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>build-helper-maven-plugin</artifactId>
    <version>3.0.0</version>
    <executions>
        <execution>
            <id>01-add-test-sources</id>
            <phase>generate-test-sources</phase>
            <goals>
                <goal>add-test-source</goal>
            </goals>
            <configuration>
                <sources>
                    <source>${project.build.directory}/generated-sources/protobuf/java</source>
                </sources>
            </configuration>
        </execution>
    </executions>
</plugin>

The problem is compounded by interaction with #322. Since I often need to close VSCode to get tests to run, the classpath gets messed up often.

There seems to be support specifically for build-helper-maven-plugin. However, there are lots of plugins which generate sources and add them to the classpath, usually under target/generated-sources. In this case, build-helper-maven-plugin is not required. VS Code should automatically recognize this. Directories like target/generated-sources and target/generated-resources could be automatically added. Alternatively, an option to configure additional classpath folders per Maven module would be welcome.

Same here. We generate Pojos for XML schemas using the jaxb2-maven-plugin. By default does classes are placed in target/generated-sources/jaxb/com/mypackage/MyGeneratedClass.java

Is there a chance to add a classpath by hand in VC code?

@fbricon

There seems to be support specifically for build-helper-maven-plugin. However, there are lots of plugins which generate sources and add them to the classpath, usually under target/generated-sources. In this case, build-helper-maven-plugin is not required. VS Code should automatically recognize this. Directories like target/generated-sources and target/generated-resources could be automatically added. Alternatively, an option to configure additional classpath folders per Maven module would be welcome.

@fbricon Any comments on the above?

I have this work project that places a few packages inside target/generated-sources and target/generated-resources and these are not being picked up by the plugin. Making it impossible for me to use VS Code with these Java projects.

Hello,

Any hope this issue gets addressed? It prevents to use java-templating plugin, CXF plugins, and a bunch of other plugins.

Thanks a lot for the hard work,
Romain

Sure, we'll investigate this in the near feature. Can't commit to a timeframe though.

Guys, if you want to make sure your use case is covered eventually, please add some small sample projects using various maven plugins contributing source folders.

@fbricon

@fbricon here it is https://github.com/rmannibucau/generated-sources-demo, just try to code/compile in Main.java through vscode (works in CLI), it will miss the two generated folder created by java-templating and wadl cxf plugin.

@rmannibucau

@rmannibucau I cloned it, ran a CLI build, opened vscode, the source folders have been added to the classpath automatically:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
	<classpathentry kind="src" output="target/classes" path="src/main/java">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="target/classes" path="target/generated-sources/java-templates">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="target/classes" path="target/generated/src/main/java">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="target/test-classes" path="src/test/java">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
			<attribute name="test" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" path="target/generated-sources/annotations">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
			<attribute name="ignore_optional_problems" value="true"/>
			<attribute name="m2e-apt" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="target/test-classes" path="target/generated-test-sources/test-annotations">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
			<attribute name="ignore_optional_problems" value="true"/>
			<attribute name="m2e-apt" value="true"/>
			<attribute name="test" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="output" path="target/classes"/>
</classpath>

Change location of generated OpenAPI sources

Solved!

In my Gradle based project I was able to fix the problem that VS Code complains about a missing generated class by explicitly adding the directory of the generated classes to the source sets in the Gradle build script build.gradle:
sourceSets {
  main {
    java {
      srcDirs 'src/main/java'
      srcDirs 'build/generated/sources/annotationProcessor/java/main'
    }
  }
}

It is a great clue. However, the srcDirs 'build/generated/sources/annotationProcessor/java/main' does not work for me.
I just changed a bit to fix it. The following configuration works for me.
Note:

I used gradle init to create the project, so the src and build are under app directory. You may not have app, so you can remove it from the path.

sourceSets {
  main {
    java {
      srcDirs = ['app/build/generated/source/proto/main/java']
    }
  }
}

Not to add clutter to this issue, but I also cannot come up with a workaround for my gradle project. I have one generated source code folder and I would like to add it as a one off, but I don't want to mess up any of the other auto class path generation. Lots of talk about Maven but not much about gradle :/

This is an existing intellij project that I really want to run in vs code because I love vs code 😭

Problem also occurs when using javaCC, even when m2e execution hint is added to pom.xml.

     <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>javacc-maven-plugin</artifactId>
        <version>3.0.1</version>
        <executions>
          <execution>
            <?m2e execute onConfiguration,onIncremental?>
            <goals>
              <goal>javacc</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <!-- See usage on maven site from link above for details -->
        </configuration>
      </plugin>
      <plugin>
        <!-- a hint for IDE's to add the java sources to the classpath -->
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <version>3.0.0</version>
        <executions>
            <execution>
            <?m2e execute onConfiguration,onIncremental?>
                <id>add-sources</id>
                <phase>generate-sources</phase>
                <goals>
                    <goal>add-source</goal>
                </goals>
                <configuration>
                    <sources>
                        <source>${project.build.directory}/generated-sources/javacc/</source>
                    </sources>
                </configuration>
            </execution>
            <execution>
              <?m2e execute onConfiguration,onIncremental?>
                <id>add-test-sources</id>
                <phase>generate-test-sources</phase>
                <goals>
                    <goal>add-test-source</goal>
                </goals>
                <configuration>
                    <sources>
                        <source>${project.build.directory}/generated-sources/javacc/</source>
                    </sources>
                </configuration>
            </execution>
        </executions>
      </plugin>

Still completely broken

@fbricon

@fbricon Here is a grpc example: https://github.com/jackielii/grpc-java-example

The problem I see is not that the generated sources are not added in the .classpath, but the grpc files are not generated or removed. Whenever I re-open the project, it removes the generated sources...

I found a workaround using this sample repo: https://github.com/jackielii/grpc-java-example. Using coc.nvim, in CocLocalConfig or global one, set:

"java.autobuild.enabled": false

This will disable initializationOptions.settings.java.autobuild.enabled in workspace initialisation. You can manually build it if it wasn't built before. More details in the README.md of this project

There should be a similar option in vscode-java as coc-java is forked from this.

I'd like to reference this comment with a repro project.

The generated sources are correctly generated by vscode but cannot be referenced in user code.

Same issue here - was using VScode just fine until a new dependency wrote to target/generated-sources/xyz and VsCode is not picking up the classes from there.

The main thing i wanted to resolve was getting the tests to be able to run individually within the vscode ide
I solved it by modifying the setting.json per the below code
note only the source paths key was necessary
Settings.json

{
    "java.compile.nullAnalysis.mode": "automatic",
    "java.configuration.updateBuildConfiguration": "interactive",
    "java.project.sourcePaths": [
        "Api/src","Api/target/generated-sources/swagger/src/main/java"
    ],
}

I found this helpful too, I think it helps with some vs-code server logic with working out how to package the classes in generated-sources with a snippet from pom
Pom.xml

<plugin>
					<!-- a hint for IDE's to add the java sources to the classpath -->
					<groupId>org.codehaus.mojo</groupId>
					<artifactId>build-helper-maven-plugin</artifactId>
					<version>3.4.0</version>
					<executions>
					<execution>
						<?m2e execute onConfiguration,onIncremental?>
						<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>

This was a useful resource to collate the discussion topics on this issue
https://github.com/redhat-developer/vscode-java/blob/master/document/_java.notCoveredExecution.md
Realistically the class paths needs to be setup correctly on vscode with the java extension pack and should be shown correctly on the configure java path settings page

This issue is particularly painful when working with JPAStreamer.
Really strange that mapstruct works but not JPAStreamer, even with org.codehaus.mojo:build-helper-maven-plugin added to pom

Sometimes I wish we could get paid support, like we have for IntelliJ.

Navigation Menu

Repository navigation

How to handle extra classpath from generated code #177

28 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

How to handle extra classpath from generated code #177

Description

Activity

fbricon commented on Apr 1, 2017

fbricon commented on May 30, 2017

fbricon commented on Aug 24, 2017

IzakMarais commented on Mar 9, 2018

IzakMarais commented on Mar 9, 2018

unguiculus commented on Dec 11, 2018

samba2 commented on Apr 9, 2019

rfgamaral commented on Jun 3, 2019

rmannibucau commented on Jun 3, 2019

fbricon commented on Jun 3, 2019

fbricon commented on Jun 3, 2019

rmannibucau commented on Jun 3, 2019

fbricon commented on Jun 3, 2019

28 remaining items

wxw-matt commented on May 21, 2022

mdgozza commented on Aug 22, 2022

timvahlbrock commented on Nov 2, 2022

davidivkovic commented on Nov 3, 2022

jackieli-tes commented on Nov 21, 2022

manuelserradev commented on Feb 4, 2023

kopiro commented on Jun 2, 2023

pythonpadawanEXE commented on Sep 7, 2023

Fabccc commented on Jan 22, 2025

bmarwell commented on Apr 13, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions