The 'auto build' should not use Maven's target folder #1381
Comments
anthonyvdotbe
changed the title
|
+1 We hit this all the time on Windows, and after blaming our anti-virus, backup software and everything else we could think of, we finally stopped using VS.code for java and everything was better. This plugin in VS.code seems to interfere with maven builds on the command-line, leading to all sorts of weird errors, especially where there are code-generation steps involved. It often manifests as "generated class does not exist" or "generated class doesn't implement an abstract method" or "generated package doesn't exist", but when we go look at the offending generated item, it is always fine after the fact. I've also seen errors reported in target class files, as in "the file XXX.class contains class YYY". |
|
I have the same problem as wheezil on Linux. It seems worse in projects with code generation. On vanilla projects vscode is ok but in workspaces with code generation it is near unusable. |
|
Hi @testforstephen. The issue doesn't really manifest in VS.code itself. It is more like VS code is continuously building and/or/analyzing the java code, and that activity (at least on Windows) seems to occur simultaneously with a "mvn install" performed on the command-line, and interferes with the maven build. I suspect that our code-generation causes updated files to be seen by VS code, and it responds immediately with its building/scanning operation to keep up to date. However, this operation (apparently) opens files in such a way that it prevents or delays visibility of files created by our code-generator or javac. We use this maven plugin to integrate the generated code: Our code-generation step is custom, basically ingesting a service IDL and generating java. This tool tries to do a "minimal update" of the target generated code, by first writing to a temporary file, and comparing to the target. If the target is missing or different, it then deletes the target and renames the temp to the target. I have seen before on Windows, that if someone has a file open, you are allowed to delete it and rename another file onto it, but global visibility of the change is somehow delayed until the file handle is closed. This may influence the issue. However, while generated code is most often seen as being involved in the issue, this is not always the case. I've also seen that .class files created during the build are reported as corrupt by later stages that attempt to use them. In all cases, when we investigate the error reported by the build, the files in question are perfectly fine. It is as if the build is getting a stale or transient snapshot of the build-product files, seeing incorrect content during a very brief window. Finally, we don't have this issue on NetBeans, although it has other problems keeping up to date with generated code -- seems like nobody really has got this right. |
|
I don't have too much to add; wheezil covered most of it. I use Java Immutables. If I run The reverse is also a problem; running maven will screw up vscode so it can't find generated/compiled files. Any time I want to run maven commands I'm forced to go through a shuffle of:
You guys would know better than me but it seems this could be avoided by having vscode use a different target directory. |
|
As a possible workaround, add the following bits to your project('s parent) pom.xml: <properties>
...
<build.output>target</build.output>
</properties>
....
<build>
<directory>${build.output}</directory>
...
</build>
...
<profiles>
<profile>
<activation>
<property><name>m2e.version</name></property>
</activation>
<properties>
<build.output>target-ide</build.output>
</properties>
</profile>
...
<profiles>this allows the build output directory to be overridden to |
|
@fbricon thanks, that is promising. I have to admit I do not know what this is doing: Do the IDEs automatically inject this property or do I need to configure them to define the property? |
|
It'll only work for IDEs based on Eclipse m2e. m2e injects the m2e.version property to the Maven reactor during incremental builds. So it's possible to activate certain profiles by checking for the presence of the |
|
@testforstephen thanks for the update. I'm not the VS.code user in our development group, but I will relay the information. Since it involves a change to the pom.xml files and not just user settings.xml it might take some negotiation to make the change. |
|
Good news! The workaround by @fbricon seems to work for us. |
|
I have the exact same problem. It would be really nice to have a workaround, or better solution, that does not involve changing the actual build files. |
|
I do not have the possibility to use the workaround, will we get a better solution to this ? |
|
Is anyone looking into this bug? Any progress/updates? |
|
This bug has been an issue for me for way too long, on a project with maven, lombok and mapstruct, and I always blamed it on some of these tools, but turns out that vscode-java is the culprit, suddenly all builds without the extension running work. |
|
For me adding this settings in settings.json helped "java.autobuild.enabled": false, |
|
Vscode should be how to configure to the automatic build to ignore a list of folder / files |
|
I've used the workaround to override the m2e build path which worked for quite a while. Guess the only option is to disable autobuild, which is definitely annoying, but at least I can use other features / plugins. |
|
I might have found a workaround if your only problem is that the build goes wrong in case of a build command from a terminal. Forget the terminal and build your project with the Maven for Java extension. You can set the profiles and execute a goal on any maven project there. This way the vscode auto build will not be triggered. |
|
Hello ! @szurilo, I re-tryed your solution but didn't work for me. Maybe, you have a specific config that work that way, may you share your settings.json ? |
I don't think my settings are specific but here you go: |
|
Okay thanks, I retried with "java.configuration.updateBuildConfiguration": "interactive", but it didn't change anything. |
|
Okay ! I think I have an answer. For those that it can help : No more random build aside maven one's :) |
The fact that the 'auto build' uses Maven's target folder is problematic. It causes independent Maven builds to fail in mysterious ways. Or even worse: the build might succeed, but the build artifacts may differ from the ones that are expected (e.g. ecj-compiled classes may end up in build artifacts, even though the Maven build itself uses javac).
Environment
Steps To Reproduce
As an example of the build that might fail:
git clone https://github.com/validator/htmlparser.git$Env:JAVA_HOME='C:\Program Files\Java\jdk1.8.0_202'build.plugins& ignore any messages about build synchronizationmvn clean source:jar javadoc:jar package repository:bundle-createin the terminalNote: this will not fail consistently, and quite often it will also just work. But that's simply because it's about uncontrollable interference between 2 processes.
Current Result
I've seen the build fail with 3 different kinds of errors already (note that the first one explicitly mentions that the failure is possibly caused by ecj-generated classes):
Expected Result
The build always succeeds and none of the build artifacts contain any ecj-generated classes.
The text was updated successfully, but these errors were encountered: