Agree, but I think this might be a viable option once Eclipse publishes their jars to central. It's going to happen, we just don't know when.
As we don't use Java 21 features, we have plenty of time to wait for this. - Ben On 19 September 2025 20:33:18 CEST, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: >Can we avoid to depend on mutable repositories for dependencies so no >eclipse jdt at all (so no spring-javaformat from what I - maybe too quickly >- saw in sources)? > >Romain Manni-Bucau >@rmannibucau <https://x.com/rmannibucau> | .NET Blog ><https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old >Blog <http://rmannibucau.wordpress.com> | Github ><https://github.com/rmannibucau> | LinkedIn ><https://www.linkedin.com/in/rmannibucau> | Book ><https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> >Javaccino founder (Java/.NET service - contact via linkedin) > > >Le ven. 19 sept. 2025 à 20:22, Jimisola Laursen <jimis...@jimisola.com> a >écrit : > >> Hi, >> >> Have you had a look at https://github.com/spring-io/spring-javaformat >> >> We opted to go with that at work. >> >> * Maven/Gradle support >> * Checkstyle support >> * Plugins/extensions for: Eclipse, IntelliJ IDEA, Visual Studio Code >> >> Regards, >> Jimisola >> >> On Fri, Sep 19, 2025 at 6:35 PM Benjamin Marwell <bmarw...@apache.org> >> wrote: >> >> > Hi everyone! >> > >> > Thanks for all your input to this thread. >> > I haven't heard back from any of the palantir maintainers either. :( >> > >> > In the meantime, I got nerd-sniped by Jan Ouwen. >> > He, too, found out that there was no "decent" code formatter. >> > Jan settled on Eclipse JDT, which he configured really close to the >> > Palantir style. The only thing he found missing was a CLI app [1]. >> > >> > So, I tried to make the config even closer to what palantir does >> > and create a CLI app to fill the gap. I got some help from Maarten, Nils >> > and Jan. So we created jfmt [2]. (Name change from jdtfmt is still in >> > progress). >> > >> > The advantages I see here: >> > * The eclipse foundation maintains Eclipse JDT >> > * Spotless can use Eclipse JDT well >> > * The CLI app is purely optional due to this fact, but if you use it, it >> > will be faster than running maven+spotless. >> > * Spotless integration makes migration to Eclipse JDT easy. >> > >> > Cons: >> > * Eclipse jar downloads are a nightmare behind corporate firewalls. They >> > still do not publish to Maven Central - yet. >> > * at least my config still needs to be refined >> > * config needs to be updated via Eclipse IDE or a 3rd party app >> > * config needs to be updated on new language features >> > >> > >> > Depending on how much the stalling progress on the palantir formatter >> > hurts us, we *could* switch to Eclipse JDT. And those who want could >> > also use a CLI app. >> > >> > @Guillaume / @Piotr: let us know if you heard something back. I did not. >> ☹️ >> > >> > - Ben >> > >> > [1]: >> > >> > >> https://jqno.nl/post/2024/08/24/why-are-there-no-decent-code-formatters-for-java/ >> > >> > [2]: https://github.com/bmarwell/jfmt >> > >> > >> > On 28/11/2024 20:31, Benjamin Marwell wrote: >> > > Hello everyone! >> > > >> > > Sadly, palantir-java-format, used in Maven builds via spotless, still >> has >> > > no support for text blocks and will misformat them. Also, it >> > > still cannot parse anonymous lambda parameters (_). >> > > >> > > Text blocks are available since 14, this bugs me already. The anonymous >> > > underscore parameter will become available for Maven on Java 21. >> > > >> > > I was not able to reach out to the maintainer. What should we do about >> > it? >> > > >> > > Option 1: just not use both features >> > > >> > > Option 2: use text blocks and deal with misalignment >> > > >> > > Option 3: use text blocks and spam // spotless:off around those >> > > >> > > Option 4: ...? >> > > >> > > Input is appreciated. I found palantir/spotless very valuable and I >> > > wouldn't want to ditch it from Maven. >> > > >> > > - Ben >> > > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > For additional commands, e-mail: dev-h...@maven.apache.org >> > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
