Hi,
We solved 13 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317122&version=12355155
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARCHETYPE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%2
Hi,
+1
Switching from Jira to GitHub brings the benefit of reducing the hurdle for
people to start contributing.
I don't have statistics but I can imagine that quite some people (who would
like to commit) don't even know we are using Jira and the mailing list. And
if they do, it is still an extra
Le 2024-10-24 à 14 h 25, Robert Scholte a écrit :
Just one question: what will happen with Maven3 users (or any other
tool) if one of their dependencies has this special type?
Rephrasing as "what will happen with a Maven 3 plugin running on Maven 4
without having been updated to the Maven 4 API
Le 2024-10-24 à 14 h 13, Robert Scholte a écrit :
What I'm seeing here is: service provides both a module descriptor
with the services, so it can be used on the modulepath At the same
time it also provides a META-INF/services to make it compatible for
the classpath as well. This is awesome to
Thanks, that's indeed long.
But seeing the result makes we wonder if the right decision has been made with
regard to pom consumption.
To me this looks like this is going to disrupt the java ecosystem.
Just one question: what will happen with Maven3 users (or any other tool) if
one of their depe
We are talking about Maven 4 plugins (the compiler, for example), so
we are talking about model version 4.1.0+ strictly here.
No Maven3 involved (or model version 4.0.0). It is in that long thread
clarified, that due shortcomings of Maven3 internals, it cannot be
done (without breaking all of it).
-Original Message-
From: Martin Desruisseaux
Sent: donderdag 24 oktober 2024 13:38
To: dev@maven.apache.org
Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Le 2024-10-24 à 13 h 17, Robert Scholte a écrit :
(about automatic modules)
> What is effective
Robert,
you might missed this quite long thread that happened about a year ago:
https://lists.apache.org/thread/x99pj75vfn5p3xtr0mvhgs5s4935j3gn
Just to get into the picture, and not repeat the whole story again :)
Thanks
T
On Thu, Oct 24, 2024 at 1:18 PM Robert Scholte wrote:
>
> Inline respo
Le 2024-10-24 à 13 h 17, Robert Scholte a écrit :
(about automatic modules)
What is effectively the difference here? As long as there's no
reference from a module descriptor to a module (either named or
automatic) there should be no difference.
The purpose of automatic modules is to allow th
Inline responses...
-Original Message-
From: Martin Desruisseaux
Sent: donderdag 24 oktober 2024 12:38
To: dev@maven.apache.org
Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
>
> Can you explain the probl
Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
Can you explain the problem you're trying to solve? In particular I
don't understand the need for modular-jar and classpath-jar, as
currently both classpath and modulepath are already build up correctly
based on the module descriptors.
The p
Can you explain the problem you're trying to solve?
In particular I don't understand the need for modular-jar and classpath-jar, as
currently both classpath and modulepath are already build up correctly based on
the module descriptors.
Thanks,
Robert
-Original Message-
From: Martin Desr
On 24.10.24 11:03, Martin Desruisseaux wrote:
About not trying anymore to be clever regarding -source versus
-release options, there is good chance that this issue is mot since
Maven 4 requires Java 17 for execution. Therefore, users should not
have reason to use -source anymore. The concern ex
Le 2024-10-24 à 07 h 57, Olivier Lamy a écrit :
I wonder if the changes have been ported to surefire and javadoc?
Not yet, but indeed those plugins will also need to be updated. We may
not be able to update them in same time as the compiler plugin. A
consequence is that some tasks that should
Le 2024-10-24 à 08 h 20, Guillaume Nodet a écrit :
Is there any technical reason why we could not port those ?
About MCOMPILER-542 (a workaround that modified the module-info.class
generated by javac versions before Java 22), there is no technical
reason apart a desire to reduce dependencies
+0 I agree that it would be a good practice to clean up, but in the end it
is not a big deal to have people listed
Thanks for raising the discussion, having these conversations about the
community itself is always a great opportunity for the project to grow and
become stronger
Some comments inli
16 matches
Mail list logo
