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,
>
> Las
...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 aroun
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
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 was
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 discu
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 consi
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, s
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 it
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 names
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) als
> 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 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 co
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 à 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 pleas
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 altern
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, opt
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 a
> 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
ove
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 y
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 à 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
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
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
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?
> >>
> > Th
24 matches
Mail list logo
