...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
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
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
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 à 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
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 à 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
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
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 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 à 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
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?
> >>
> >
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?
This is exactly the case, module-info is injected somehow - a common
case is by generating its bytecode but
Le mer. 3 janv. 2024 à 19:25, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-03 à 17 h 15, Romain Manni-Bucau a écrit :
>
> > see it as "where classpath is in core comes from the time maven was
> > only for java libs" (i'd say maven 2 cause I don't know maven 1).
>
Le 2024-01-03 à 17 h 15, Romain Manni-Bucau a écrit :
see it as "where classpath is in core comes from the time maven was
only for java libs" (i'd say maven 2 cause I don't know maven 1).
The CLASSPATH_CONSTITUENT property and related isAddedToClasspath()
methods were added in Maven 4. I let
Le mer. 3 janv. 2024 à 17:03, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-03 à 16 h 45, Romain Manni-Bucau a écrit :
> > maven4 introduces the notion of "services" (...snip...) So guess all
> > is there to do it and core can stay as this for backward compat
> >
Le 2024-01-03 à 16 h 45, Romain Manni-Bucau a écrit :
maven4 introduces the notion of "services" (...snip...) So guess all
is there to do it and core can stay as this for backward compat
(maven4 must support maven3) but nothing more.
Current services are class-path aware, with
Le mer. 3 janv. 2024 à 16:11, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-03 à 15 h 19, Romain Manni-Bucau a écrit :
>
> > I can agree with that so let's move it in a plugin related code maybe?
> >
> The call is on core Maven developers. If Tamas (or someone
Le 2024-01-03 à 15 h 19, Romain Manni-Bucau a écrit :
I can agree with that so let's move it in a plugin related code maybe?
The call is on core Maven developers. If Tamas (or someone else) moves
everything related to class-path to another location, I will follow. But
I think it would need
Le mer. 3 janv. 2024 à 14:45, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-03 à 12 h 08, Romain Manni-Bucau a écrit :
> >> I would like to see a proof in the form of an "hello world"
> >> application (…snip…)
> >
> > Yot got some on github.
> >
> Can you share
Le 2024-01-03 à 12 h 08, Romain Manni-Bucau a écrit :
I would like to see a proof in the form of an "hello world"
application (…snip…)
Yot got some on github.
Can you share the URL?
defaulting on the classpath is fine only if the library developers
applied workarounds (…snip…)
The
Le mer. 3 janv. 2024 à 11:50, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-03 à 09 h 08, Romain Manni-Bucau a écrit :
>
> > (…snip…) just to answer trivially to "But if an artifact is included,
> > it should (at least by default) always be placed consistently on
Le 2024-01-03 à 09 h 08, Romain Manni-Bucau a écrit :
(…snip…) just to answer trivially to "But if an artifact is included,
it should (at least by default) always be placed consistently on the
class-path or module-path.", it is obvious it is not the case for
several plugins like surefire
Martin I can understand that theorically your proposal look good but just
to answer trivially to "But if an artifact is included, it should (at least
by default) always be placed consistently on the class-path or
module-path.", it is obvious it is not the case for several plugins like
surefire
Le 2024-01-02 à 20 h 51, Romain Manni-Bucau a écrit :
RMB: so you mean you don't intend to link the classpath to the type?
Not directly. The code dispatching JAR files between classpath,
module-path, etc., bases fully its decision on the following:
* DependencyProperties
* Sometime
Le mar. 2 janv. 2024 à 18:46, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Hello Romain
>
> Le 2024-01-02 à 18 h 16, Romain Manni-Bucau a écrit :
>
> > In other words you deprecated isAddedToClasspath cause it was too
> > rigid to put in place something as rigid which
Hello Romain
Le 2024-01-02 à 18 h 16, Romain Manni-Bucau a écrit :
In other words you deprecated isAddedToClasspath cause it was too
rigid to put in place something as rigid which enables one rare
(today) case so I'm not very enthusiatic about it.
The proposed replacement is not as rigid,
Hi Martin,
Think this propagate current lock situation where you only work in a
particular subset of builds so I still think we should extract
getDispatchedPaths , PathType etc to something like maven-shared (or
nothing) and just make this logic owned by plugins, this is the only
location it
Le 2024-01-02 à 17 h 44, Martin Desruisseaux a écrit :
(…snip…) First, the (class, module, etc.)-paths, later the source
directories (I wish Maven supports Module Source Hierarchy), in which
case I will try to address multi-releases in same time.
Actually, I have been silent on this topic in
Hello David
Le 2024-01-02 à 17 h 36, David Lloyd a écrit :
Apologies if this was already covered somewhere else, but would (or
could) path accumulation support multi-release JAR layouts for all
cases (whether it be modular or class-path JARs or filesystem paths)?
The current proposal does
Apologies if this was already covered somewhere else, but would (or could)
path accumulation support multi-release JAR layouts for all cases (whether
it be modular or class-path JARs or filesystem paths)?
On Tue, Jan 2, 2024 at 10:13 AM Martin Desruisseaux <
martin.desruisse...@geomatys.com>
34 matches
Mail list logo
