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, 08:28, Christoph Läubrich <m...@laeubi-soft.de> a écrit : > This does not clarify anything for me, again JDT is already published to > maven central, so even if you don't trust "Eclipse Hosted Repository" > (of whatever format) I'm a bit clueless on what JDT needs to be "catch > up" with here? > Versions we do not already support > e.g Tycho uses JDT and even plexus-compiler-jdt of course both are on > maven central and none of these would work if their dependencies where > not there. > > Am 20.09.25 um 08:18 schrieb Romain Manni-Bucau: > > 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 > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
