@ctrimble I’m not sure applying the style all at once is a good idea, but I wanted to show the impact and highlight whether thejsonschema2pojo-eclipse-formatter.xml should be updated to reduce the diff.
Once you’ve confirmed the file is correct, I can drop the commit with the changes and replace it witha gradual check.

@juherr Thanks for submitting this. but it is a distraction right now. I will take a look when the backlog is more in order.

Sure, it is not urgent

I'll add my 2 groszy to the discussion.

Back in the day I've resigned from spotless plugin both at work and in personal projects because it's annoying: you need to hack a solution to test if it works and… you have to format.

Additionally, it take too much time to run, so no rapid development either.

We at work and I in my personal projects usually on commit or even on push (depending on team and project), so pre-commit (or any similar project) checked both locally and on CI works the best.

@eirnym I didn’t bind the plugin to any Maven phase and added a CI check as you suggested.
I can also add a few words to explain how to run the plugin on a Git event.

That’s exactly what you had in mind, right?

I haven't read Spotless for a while now, but AFAIK it binds itself to the build phase like it was back in the day. It's easy to check: just make code less pretty and build the project

I’ve been using Spotless on many of my projects and haven't run into the issue you mentioned. ;)

I've checked documentation and it's not automatic as you've said. But it's a separate non-automated execution which is still not ideal. It's easy to forget run<build> spotless before commit.

It's possible to write a manual pre-commit hook, but it's still not automated.

@eirnym Did you seehttps://github.com/diffplug/spotless/tree/main/plugin-maven#git-hook ?

Yes, I did. It's not so easy to manage (keep, install, update) and it's not extensible as pre-commit is.

It's may be ok for a very small project which won't add any other pre commit hooks ever. In teams and in project I work, this tool was replaced with almost direct run of formatters spotless calls.

as of specific hooks to use for format, I recommend to look at this one:https://github.com/macisamuele/language-formatters-pre-commit-hooks

As an alternative location to bind this, I have a format lifecycle published. I haven't used it in a while, but we could add anmvn format lifecycle and then bind this plugin to that. That may be a better location for the license header as well. That plugin is always causing me issues with conflicts in my IDE.

@ctrimble What do you mean exactly?
Are you suggesting creating a custommaven-format-plugin that supports<plugins> in its configuration,
or overriding the default Mavenjar lifecycle by adding a new step to it?

@juherr We could addhttps://github.com/ctrimble/maven-format-lifecycle to the project. Then we would havemvn format from the command line. It just creates a maven lifecycle that has nothing to do with the build.

I haven't messed with that in a few years, but I am not aware of any breaking changes in maven that have broken lifecycle plugins.