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?
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
