Le 2024-01-04 à 15 h 56, Romain Manni-Bucau a écrit :
Well it was written that the artifact names were not JPMS compatible,
you can review https://github.com/apache/geronimo-specs but it was
just one example.
Without link to the specific section, I cannot review if it is related
to our
Le jeu. 4 janv. 2024 à 16:21, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-04 à 15 h 56, Romain Manni-Bucau a écrit :
>
> > Well it was written that the artifact names were not JPMS compatible,
> > you can review https://github.com/apache/geronimo-specs but it
...check it out again but you also said "it does not work" so still not, as
soon as one lib is not jpms compatible (not by not being a module but by
not being consummable even with implciit name as explained in this example)
you can't use jpms first but you can always workaround the other way
Well it was written that the artifact names were not JPMS compatible, you
can review https://github.com/apache/geronimo-specs but it was just one
example.
Don't get me wrong but indeed you can fix all the world to make it fully
JPMS compatible, this is not what happent since java 9 so I don't
Le 2024-01-04 à 17 h 01, Romain Manni-Bucau a écrit :
We didnt speak of that but consuming that in a classpath/module
friendly project.
This part was answered: build as JPMS + workarounds. The
counter-argument was that it should be built as class-path + workarounds
instead, which I tried to
for the records, "Maven Plugins Compatibility Plan" strategy is stored in
https://maven.apache.org/developers/compatibility-plan.html
= the doc to refer to and update if necessary after the current discussion
Le vendredi 29 décembre 2023, 14:42:17 CET Slawomir Jaranowski a écrit :
> Hi,
>
>
Le jeu. 4 janv. 2024 à 01:23, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-03 à 21 h 31, Romain Manni-Bucau a écrit :
>
> >> Can you compile this test case with the dependency on the class-path,
> >> without omitting the module-info in the compilation?
> >>
> >
Hi all,
Reviewing and trying to follow Martin's thread about JPMS I thought about
the old issue that our build pipelines (plugins chain) is very hard to
customize.
Guillaume added the priority case but the clean solution proposed
originally was to define custom lifecycles (to add frontend, docker
> Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
Not completely sure, but of course all would need to inherit the same
parent, maybe one can allow to "import" pom with plugin configuration as
an alternative, but for extension.xml it is the same you need to copy it
Isn't it already possible to "extend" the lifecycle by simply putting
plugin + execution into root pom?
Main problem for me is that currently packaging == type == lifecycle,
otherwise one could simply have an "empty" lifecycle + whatever
packaging and simply bind anything you want tin pom.xml
Le 2024-01-04 à 09 h 21, Romain Manni-Bucau a écrit :
Please just stip thinking jpms first, think classpath first with jpms
compat, changes the whole perspective. If i want classpath compat more
than jpms why would i do everything with module and miss my 80% case?
Because doing everything as
Hi Christoph,
commented inline
Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich a
écrit :
> Isn't it already possible to "extend" the lifecycle by simply putting
> plugin + execution into root pom?
>
Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
For a single module
Le jeu. 4 janv. 2024 à 10:54, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-04 à 10 h 27, Romain Manni-Bucau a écrit :
>
> > You also explained this is not true since you cannot compile part of
> > the code linked to optional depswhich go against JPMS
> >
> No,
Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich a
écrit :
> > Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
>
> Not completely sure, but of course all would need to inherit the same
> parent, maybe one can allow to "import" pom with plugin configuration as
> an
Le 2024-01-04 à 11 h 31, Romain Manni-Bucau a écrit :
No, optional dependencies in JPMS are handled by "static requires".
As explained in previous post it is not always possible cause JPMS
enforces constraints which are not always respected.
I don't understand what you mean. Test case
Le jeu. 4 janv. 2024 à 10:20, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-04 à 09 h 21, Romain Manni-Bucau a écrit :
>
> > Please just stip thinking jpms first, think classpath first with jpms
> > compat, changes the whole perspective. If i want classpath compat
Le 2024-01-04 à 10 h 27, Romain Manni-Bucau a écrit :
You also explained this is not true since you cannot compile part of
the code linked to optional depswhich go against JPMS
No, optional dependencies in JPMS are handled by "static requires".
You will also note the compile time check is
Le jeu. 4 janv. 2024 à 11:42, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-04 à 11 h 31, Romain Manni-Bucau a écrit :
>
> >> No, optional dependencies in JPMS are handled by "static requires".
> >>
> > As explained in previous post it is not always possible cause
Le 2024-01-04 à 12 h 49, Romain Manni-Bucau a écrit :
Just take the previous example you even explained yourself with an
invalid JPMS name, this is still a valid case today.
Module names are like any other symbol names (classes, methods, etc.).
If a module name is invalid, we want the same
> Why? extension is global for the project so no copy needed.
If you want to use it in different project I'm not aware how you can
share extension.xml between them ... but a pom deployed somewhere can be
reused (in pom.xml) also extension/extensions.xml cant contain any
configuration)
> You
Le jeu. 4 janv. 2024 à 13:17, Christoph Läubrich a
écrit :
> > Why? extension is global for the project so no copy needed.
>
> If you want to use it in different project I'm not aware how you can
> share extension.xml between them ... but a pom deployed somewhere can be
> reused (in pom.xml)
Le jeu. 4 janv. 2024 à 13:05, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-04 à 12 h 49, Romain Manni-Bucau a écrit :
>
> > Just take the previous example you even explained yourself with an
> > invalid JPMS name, this is still a valid case today.
>
> Module
Le 2024-01-04 à 14 h 24, Romain Manni-Bucau a écrit :
Cause it just works (and was forking for years). Geronimo specs jar
have this issue for ex and this is not a blocker for lib builders to
consume them, build with them and produce a JPMS friendly jar.
Still no test case for proving that
Hi,
When deploying artifacts to Nexus repository, 400 Bad Request can be
one of the most confusing error code. See [1] as an example.
Sonatype has a page to document some common causes of 400 Bad Request
[2]. But I wonder if we can return an error message (diagnostic) along
with the error code,
24 matches
Mail list logo
