Le 2025-04-01 à 11 h 07, Gary Gregory a écrit :
I suppose it feels like Java is still being developed in an ivory
tower away from the real world. The constant reinventing the wheel
(logging and http client APIs are obvious examples). I suppose OSGi
vs. JPMS could fall into this category.
The b
On Tue, Apr 1, 2025, 10:19 Piotr P. Karwasz
wrote:
> Hi Martin,
>
> On 1.04.2025 11:03, Martin Desruisseaux wrote:
> > Le 2025-04-01 à 10 h 49, Piotr P. Karwasz a écrit :
> >> The https://github.com/nipafx/module-tooling/ repo seems to be
> >> private. Is there any public place to follow the disc
Hi Martin,
On 1.04.2025 11:03, Martin Desruisseaux wrote:
Le 2025-04-01 à 10 h 49, Piotr P. Karwasz a écrit :
The https://github.com/nipafx/module-tooling/ repo seems to be
private. Is there any public place to follow the discussion?
Not as far as I know. The initiator of this discussion wan
Hi Martin,
Thank you for your thoughtful comments.
I suppose it feels like Java is still being developed in an ivory tower
away from the real world. The constant reinventing the wheel (logging and
http client APIs are obvious examples). I suppose OSGi vs. JPMS could fall
into this category.
All
Typo:
Le 2025-04-01 à 10 h 17, Martin Desruisseaux a écrit :
It would require the maven-jar-plugin to generate one JAR per Maven
module.
Was intended to be "one JAR per Java module".
Martin
-
To unsubscribe, e-mail: d
Le 2025-04-01 à 10 h 49, Piotr P. Karwasz a écrit :
The https://github.com/nipafx/module-tooling/ repo seems to be
private. Is there any public place to follow the discussion?
Not as far as I know. The initiator of this discussion wanted to keep it
private, I'm not sure why. This topic has be
Le 2025-04-01 à 08 h 37, Gary Gregory a écrit :
What Piotr describes is sadly the kind of insane setup one must have
to work with JPMS and keeps me saying JPMS is something to work
around, not work with.
I think that what Piotr described is a Maven issue, not a JPMS issue.
The problem is that
Hi Martin,
On 1.04.2025 10:17, Martin Desruisseaux wrote:
I am also afraid that such a structure will really break IDEs:
Eclipse already breaks if there is a separate module descriptor for
tests, putting multiple JPMS modules in the same Maven Project will
probably also break IDEA.
Yes, it w
Hello Piotr
Le 2025-04-01 à 08 h 20, Piotr P. Karwasz a écrit :
I fail to understand, however, the purpose of the "modular project"
layout.
All modules are compiled in one single calls to `javac`. It is not one
call of `javac` per module. The benefit is that forward references to
dependent
What Piotr describes is sadly the kind of insane setup one must have to
work with JPMS and keeps me saying JPMS is something to work around, not
work with. I plan on keeping using hacks like the Moditect plug-in and
whatever I have to in my apps to avoid JPMS. What I really want is a
--jpms-off too
Hi Martin,
On 31.03.2025 19:40, Martin Desruisseaux wrote:
JPMS support in the compiler plugin (not yet merged) has reached a
point where it can be used on some real projects. The Maven 3 way to
make a modular project is still supported, but the proposed
alternative for better use of JPMS is d
Hello all
JPMS support in the compiler plugin (not yet merged) has reached a point
where it can be used on some real projects. The Maven 3 way to make a
modular project is still supported, but the proposed alternative for
better use of JPMS is described here:
*
https://github.com/Geomatys/
12 matches
Mail list logo
