Well to clarify, my target would be * M2 standard layourt with enforced immutability bu trusted hoster (so central and no P2) * Something bringing more than spotless we ARE happy about (so java 17 is not a topic, more 21+)
My blind guess is that spotless ecosystem will catch up once jdt reaches these contraints so no need to do anything on our side IMHO 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 sam. 20 sept. 2025, 07:14, Christoph Läubrich <m...@laeubi-soft.de> a écrit : > I'm really a bit confused about opinions state as fact here. > > First, Eclipse Simrel releases (that seems referenced here a bit hard to > tell from vague complaints) are stable and never change, they are even > more less "mutable" than maven central, because after the release even > no new artifacts are ever added there (in contrast to central where new > versions arise every day and modify the metadata). > > Second Eclipse Platform as well as JDT release "their jars" to maven > central since > 10 years now [1] (again I just can guess what exactly is > needed here there are many more of course). > > Last but not least because of that there are versions that support Java > 8 / 11 / 17 as well and most of the time API is stable enough so you can > just choose (maybe using a profile). > > [1] https://repo1.maven.org/maven2/org/eclipse/jdt/org.eclipse.jdt.core/ > > Am 19.09.25 um 23:26 schrieb Benjamin Marwell: > > 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
