Alternatives to groovy eclipse formatter?

[scottresnik]

The groovy eclipse formatter is very inconsistent with regard to formatting groovy and gradle files. This isn't spotless's problem, as similar behavior is apparent in Eclipse with the Groovy plugins installed. However, I thought this would be a good place to ask if anyone had discovered any alternatives.

As an example, this line:

ext {
  aSet = ['abcd','sdfsdfb','sdfsdfdsc','sdsdfdsdfdsfd'] as Set<String> 
}

spotlessCheck will not fail because of that block, yet spotlessApply will change it to:

ext {
  aSet = [
    'abcd',
    'sdfsdfb',
    'sdfsdfdsc',
    'sdsdfdsdfdsfd'] as Set<String>
}

I can create odd variances of the above, by moving the trailing brace of the block up. The formatter seems to really only trigger a failure consistently if the gradle files is very poorly formatted.

I have a sample project here that illustrates the problems with the groovy eclipse formatter: https://github.com/scottresnik/spotless-wildcard

Anyone have any good alternatives that work well with spotless?

[fvgh]

I am afraid I found no better alternative. Proposals are always welcome and I can assist with (or maybe even implement) the Spotless integration.

Remember that the formatter is only one step in a formatting chain, so you can work-around some problems like I once demonstrated here.
But for gradle, I admit that groovy-eclipse is just better than nothing...

There are also some inconveniences for groovy, as you see at the end of #237. But I am confident that the groovy-eclipse team will address them.

[bitwiseman]

CodeNarc will detect all kinds of formatting violations in Groovy, but it won't fix them. There's project called npm-groovy-lint that will fix violations, but it is still in "beta". Also having a Java tool that calls Node.js that calls Java... 😭

[nedtwigg]

having a Java tool that calls Node.js that calls Java

Can work! We've got infrastructure for node.js-based formatters. But if the core of npm-groovy-lint is already java, probably easier to just replicate the node logic in java. Regardless, I think the best bet is probably to help the groovy-eclipse project, but the bar for merging a new formatter is low, happy to try experiments.

spotlessCheck will not fail because of that block, yet spotlessApply will change it to:

This should never happen, because of paddedCell, which is always enabled in Spotless. If this happens, it means that the groovy formatter is somehow storing state from function call to function call. Two possible fixes:

• find anywhere that groovy-eclipse does caching, and remove it
• create an "isolated" mode in our groovy integration, which would load create a classloader and load classes, format a file, then close the classloader. New classloader per format call. Very slow, but it would remove all hidden state, which would guarantee perfect consistency between apply and check.

In general, I think the best ROI would be fixing the bugs in groovy-eclipse directly, but there are other paths.