Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enum bug in eclipse 4.8.0 (default should be 4.7.3) #263

Closed
2 tasks
nedtwigg opened this issue Jul 20, 2018 · 4 comments
Closed
2 tasks

Enum bug in eclipse 4.8.0 (default should be 4.7.3) #263

nedtwigg opened this issue Jul 20, 2018 · 4 comments
Labels

Comments

@nedtwigg
Copy link
Member

I tested out 3.14.0-SNAPSHOT, which now has @fvgh's great new eclipse framework in place. It worked great, except for a known bug. You already pointed it out Frank, but after using it on some large projects, I think we should not make 4.8.0 the default eclipse version.

There is a bug in the 4.8.0 formatter which causes all enums to be indented strangely. Instead of this:

public enum {
  ONE, TWO;

  public int asNumber() {
    return ordinal();
  }
}

We get this:

public enum {
ONE, TWO;

  public int asNumber() {
    return ordinal();
  }
}

The bug is tracked at eclipse as 536322, and it's already fixed for the next release. Since it's a pretty big behavior change and it's only present in 4.8.0, I think we should skip it as the default.

Only trouble is, it seems we're missing the lockfile for 4.7.3, and also for 4.6.2. I think we should:

  • add lockfile for 4.6.2 and 4.7.3
  • change the default to 4.7.3, with a note that we're skipping 4.8.0 as default because of this issue

Once this is done, I'm ready to cut a new release! Would you like to merge #241 and #238 first, @fvgh?

@nedtwigg nedtwigg added the bug label Jul 20, 2018
@fvgh
Copy link
Member

fvgh commented Jul 20, 2018

No, please continue. Both pending PRs still contain copy&paste of plugin configuration from Eclipse. I fixed that already for Eclipse-Groovy (GrEclipse). Furthermore I am afraid we still have to make a minor enhancement on lib/lib-extra. I will show you later on. Don't worry, everything I have merged so far is working... (except of this problem 😄 ).

Do you want me to provide the fix for this issue?

Out of curiosity, I used search.maven.org, to see which old versions of spotless-ext-eclipse-jdt are available. 4.6.2 and 4.7.3 didn't and don't show up. Can you recommend another tool to search Maven Central?

@nedtwigg
Copy link
Member Author

You are correct that 4.6.2 and 4.7.3 don't exist for spotless-ext-eclipse-jdt. But goomph knows about them, so we should be able to make a lockfile for them. If you don't have time to provide the lockfiles, can you point me to instructions for how to make them?

@fvgh
Copy link
Member

fvgh commented Jul 20, 2018

In this case, maybe I should explain the missing bit in lib/lib-extra. Then you better work on that one. Not much to do, but some one has to determine how to change the interface and I would prefer to leave that to you. One mom., just opening a new PR demonstrating the problem...

@fvgh
Copy link
Member

fvgh commented Jul 20, 2018

Please have a look at #264 and decide whether we need a fix for this release.
You explained how goomph works, but keep in mind that (at least for 4.6.2) not all required versions might be available on M2. If I shall provide a fix for 4.7.3, I would basically just change the org.eclipse.jdt:org.eclipse.jdt.core version. The Eclipse OSGI versions you can't change anyhow, since com.diffplug.spotless:spotless-eclipse-base interface implementation depends on them. But I see not a point to ape Eclipse versions completely. These new versions of OSGI interfaces are backward compatible and have no impact on the formatter result at all. Same is true for core runtime, resources and commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants