spotless 3.8.0
21:21:13.863 [ERROR] [com.diffplug.spotless.Formatter] Step 'eclipse formatter' found problem in 'src/main/java/com/[...]/config/schema/[FieldSchema.java](https://github.com/diffplug/spotless/files/1650522/FieldSchema.txt)
':
null
java.lang.reflect.InvocationTargetException
at com.diffplug.spotless.extra.java.EclipseFormatterStep$State.lambda$createFormat$0(EclipseFormatterStep.java:100)
at com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
at com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
at com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:263)
at com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:205)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
at org.gradle.api.internal.project.taskfactory.IncrementalTaskAction.doExecute(IncrementalTaskAction.java:46)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:121)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:110)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:92)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70)
at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62)
at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:60)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:97)
at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:87)
at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98)
at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:626)
at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:581)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Caused by: java.lang.IllegalStateException: Workspace is closed.
at org.eclipse.core.resources.ResourcesPlugin.getWorkspace(ResourcesPlugin.java:412)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.createParser(DefaultCodeFormatter.java:332)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.parseSourceCode(DefaultCodeFormatter.java:317)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareFormattedCode(DefaultCodeFormatter.java:213)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareFormattedCode(DefaultCodeFormatter.java:206)
at org.eclipse.jdt.internal.formatter.CommentsPreparator.formatCode(CommentsPreparator.java:1063)
at org.eclipse.jdt.internal.formatter.CommentsPreparator.handleFormatCodeTag(CommentsPreparator.java:801)
at org.eclipse.jdt.internal.formatter.CommentsPreparator.handleHtml(CommentsPreparator.java:665)
at org.eclipse.jdt.internal.formatter.CommentsPreparator.endVisit(CommentsPreparator.java:621)
at org.eclipse.jdt.core.dom.TagElement.accept0(TagElement.java:282)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2796)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2867)
at org.eclipse.jdt.core.dom.Javadoc.accept0(Javadoc.java:205)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2796)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareComments(DefaultCodeFormatter.java:399)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareFormattedCode(DefaultCodeFormatter.java:222)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:177)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:160)
at com.diffplug.gradle.spotless.java.eclipse.EclipseFormatterStepImpl.format(EclipseFormatterStepImpl.java:38)
... 47 more
Can you show the code of src/main/java/com/sophos/nsg/sep/config/schema/FieldSchema.java? It's crashing the formatter.
It's linked in my first post.
@d1ss0nanz What "first post" are you referring to? :)
The first "comment" in this issue.
FieldSchema.java
Let me know if you need anything else.
Can you show us the eclipse config that you're using? eclipse('4.7.2').configFile(....?
Does it have .txt extension in your project? There are different formats, and we use the extension to determine what kind of file it is. It should have .xml extension, because it is xml.
So, it should be eclipse('4.7.2').configFile('eclipse_formatter_settings.xml'). If this fixes it, then we need a better error message. It seems like we do throw a descriptive exception, though...
It's .xml, but I can't upload XML files here, so I had to change the file extension.
Here's my actual config:
apply plugin: "com.diffplug.gradle.spotless"
buildscript {
dependencies {
classpath "com.diffplug.spotless:spotless-plugin-gradle:3.8.0"
}
}
spotless {
java {
eclipse('4.7.2').configFile 'spotless.eclipseformat.xml'
ignoreErrorForPath('[...]/config/schema/FieldSchema.java')
}
}
Please let me know if you need any other information.
Sorry, I'm stumped. The ignoreErrorForPath is at least a workaround, correct?
Yes, ignoreErrorForPath is preventing the task to fail. The exception is still thrown, but that's more a cosmetic issue.
Found the cause of the exception:
When I remove <pre> and </pre> in lines 33 and 37 no exception is thrown.
Fascinating! I think the eclipse formatter is smart enough that it looks at the imports and uses them for javadoc {@link tags. I wonder if tries to do something fancy with code examples that requires compiled project info, thus triggering the workspace is closed error when it tries to look for project metadata.
Seems like a hard problem to track all the way down. Happy to take a PR, but unlikely to see a fix.
Same error here with spotless 3.9.0
Removing <pre> and </pre> from source files fix the problem but I don't like that :|
Just FYI with eclipse oxygen, spotless 3.9.0 -- in eclipse I have no issue formatting the code. spotlessApplyJava however exceptions with the same message as the OP.
There is a formatter setting that determines whether java source code inside of a pre block gets formatted:
<setting id="org.eclipse.jdt.core.formatter.comment.format_source_code" value="false"/>
The default value is true, maybe false is a workaround?
Setting this to false isn't a workaround.
The problem is in the JDT code formatter. Due to pre it tries to created a new parser for the Java code within pre tags. The formatter requires a compilation unit (so in the end files). Since JDT now supports Java 9, it also requires a module-info.java. So what JDT now does is an assembly of fake paths. To make up these fakes, it uses the Eclipse work-space. But spotless has/requires no work-space, so the module is not initialized.
The only work-around I see is to set the following properties to FALSE:
Note that both must be set to false.
Will provide a fix ASAP, but it will take a while before it'll be available on Maven Central.
Hello,
Same error, also with a <pre> and </pre> tag in my java documentation.
I use com.diffplug.spotless:spotless-plugin-gradle:3.12.0
Thanks.
Thanks to a monumental effort from @fvgh, this has been fixed in plugin-gradle 3.14.0 and plugin-maven 1.14.0.
I still encountered issues with <pre> and any sort of comments in general when using the gradle v3.14.0 or v3.15.0 plugin with the following config:
eclipse('4.7.2').configFile('eclipse-formatter.xml')
They seem to be bugs in the eclipse formatter itself, and not the fault of this plugin.
Thus, I could only workaround it by exporting a formatter.xml with comment formatting unchecked. I.E.
P.S. I would use the eclipse formatter v4.8.x, but that version introduced various unrelated formatting bugs. Thus I'm stuck with v4.7.x or the future v4.9.x.
Sorry @achaphiv , but a back-port of the bug-fix was never foreseen. There are known issues with 4.8.x, like reported with #263. Hence I additionally provided 4.7.3a. But this is also not an option for you?
Can you name a formatting problem with 4.7.3a (small example). 4.9 has been published in Maven central last moth. Will provide a new release if it helps.
Sure, here's an example project that demonstrates one of the more annoying issues I encountered.
https://github.com/achaphiv/spotless-problem/
The following simple class uses 100% CPU and seems to cause an infinite loop:
public class CausesEndlessExecution {
// one
// two
{
if (
true
) {}
}
}
Tested on mac (java 1.8.0_172) and linux (openjdk 1.8.0_181).
Bizarre right? Those two comments combined with the multi-line if somehow cause the weirdness.
It fails on any eclipse version.
I.E.
eclipse().configFile('eclipse-formatter.xml')
eclipse('4.7.3a').configFile('eclipse-formatter.xml')
eclipse('4.7.2').configFile('eclipse-formatter.xml')
eclipse('4.8.0').configFile('eclipse-formatter.xml')
I eventually just gave up and disabled all comment formatting to sidestep all these issues.
@achaphiv Thanks for the input. Please give me some days to dig into it. Looks like some different bug.
@achaphiv
I can reproduce the problem, within Eclipse IDE and with Spotless.
But the problem seems not be related to line-comment or JavaDoc, since regardless of these two settings, the problem occurs. Can you confirm? In this case I really would like you to open another issue, if you think it's something I should look into.
To me it seems that some other preference correlation causes the problem:
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
at org.eclipse.jdt.internal.formatter.linewrap.WrapExecutor.findWraps(WrapExecutor.java:526)
at org.eclipse.jdt.internal.formatter.linewrap.WrapExecutor.findWrapsCached(WrapExecutor.java:403)
at org.eclipse.jdt.internal.formatter.linewrap.WrapExecutor$WrapsApplier.newLine(WrapExecutor.java:252)
at org.eclipse.jdt.internal.formatter.linewrap.WrapExecutor$WrapsApplier.token(WrapExecutor.java:225)
at org.eclipse.jdt.internal.formatter.TokenTraverser.traverse(TokenTraverser.java:103)
at org.eclipse.jdt.internal.formatter.TokenManager.traverse(TokenManager.java:383)
at org.eclipse.jdt.internal.formatter.linewrap.WrapExecutor.executeWraps(WrapExecutor.java:366)
at org.eclipse.jdt.internal.formatter.linewrap.WrapPreparator.finishUp(WrapPreparator.java:1034)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareWraps(DefaultCodeFormatter.java:426)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareFormattedCode(DefaultCodeFormatter.java:224)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:178)
at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:161)
at com.diffplug.spotless.extra.eclipse.java.EclipseJdtFormatterStepImpl.format(EclipseJdtFormatterStepImpl.java:44)
at com.diffplug.spotless.extra.java.EclipseJdtFormatterStep.lambda$apply$0(EclipseJdtFormatterStep.java:51)
at com.diffplug.spotless.extra.java.EclipseJdtFormatterStep$$Lambda$87/605353830.apply(Unknown Source)
at com.diffplug.spotless.FormatterFunc.apply(FormatterFunc.java:31)
at com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
at com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
at com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:264)
at com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:205)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
It is irritating the the Eclipse JDT preference editor does not prevent these malicious settings.
Anyhow, I am afraid I cannot investigate further, since it seems to be JDT problem and the latest JDT does not behave differently.
If you find anything that works with your Eclipse IDE but not with Spotless, let me know.
But the problem seems not be related to line-comment or JavaDoc, since regardless of these two settings, the problem occurs. Can you confirm?
I only made one change to the eclipse-formatter.xml and my test project works in both spotless/eclipse:
-<setting id="org.eclipse.jdt.core.formatter.comment.format_line_comments" value="true"/>
+<setting id="org.eclipse.jdt.core.formatter.comment.format_line_comments" value="false"/>
In this case I really would like you to open another issue, if you think it's something I should look into.
Hmm, probably not necessary. Definitely looks like an Eclipse issue.
I made my original comment because I thought it worked in the IDE, but not spotless. But I see my test project freezing in the IDE as well. I was likely running into at least 2 separate issues:
4.7.3a+.If you find anything that works with your Eclipse IDE but not with Spotless, let me know.
I'll be on lookout, but Eclipse 4.9 (2018-09) still seems to have issues with line comments, so I've turned off all comment handling in both eclipse/spotless to avoid all current and future comment-related issues.
@achaphiv
When I found that the problem also occurs in Eclipse IDE, I tested with the default Eclipse Photon build-in preferences. It has format_line_comments set to true and works. I tried to change some of the preferences according to your configuration, but could not quickly determine where exactly the problem is.
I think you have found a really nasty bug in JDT and your example is very good.
Maybe you want to consider to raise a bug report in the Eclipse bug tracker.
It took a while, but with my settings my Photon Eclipse got out of memory with your example, like Spotless did on my system.
As soon as I am aware about an Eclipse version that fixes formatter bugs or has any enhancements in that respect, I am happy to provide a new Spotless Eclipse JDT version.
Sorry that I was not able to help you, with your current problem.
The original bug tile is misleading. Every exception which occurs within a Spotless Eclipse implementation leads to a java.lang.reflect.InvocationTargetException on Spotless plugin level. The cause of the exception (in this case "java.lang.IllegalStateException"), is the important one.
Most helpful comment
Problem
The problem is in the JDT code formatter. Due to
preit tries to created a new parser for the Java code withinpretags. The formatter requires a compilation unit (so in the end files). Since JDT now supports Java 9, it also requires a module-info.java. So what JDT now does is an assembly of fake paths. To make up these fakes, it uses the Eclipse work-space. Butspotlesshas/requires no work-space, so the module is not initialized.Work-Around
The only work-around I see is to set the following properties to
FALSE:Note that both must be set to false.
Solution
Will provide a fix ASAP, but it will take a while before it'll be available on Maven Central.