On 05.01.24 17:02, Michael Osipov wrote:
On 2024/01/05 15:52:54 Karl Heinz Marbaise wrote:
...
On 05.01.24 16:19, Michael Osipov wrote:
On 2024/01/05 14:37:44 Karl Heinz Marbaise wrote:
+1 Also the point JDK11 (maybe even higher JDK17?) for Maven 4.0.0 as
minimum runtime requirement..
This reminds me of https://github.com/openssl/openssl/issues/10902 and it
provides very good reasons why not to do it. Maven is a low level tool -- as
such it has to be available to as many devs as possible.
Hm.. I have to admit that I don't see the relationship to OpenSSL and
C++ compilers / Perl etc. and which reason do you have in mind?
It is about replacing Perl with CMake. Perl has a much better availability than
CMake...
And where is the relationship to Maven? Apart from that Perl is not that
available on a lot of systems (the last 10 years have changed that)...
today Python is often more available than Perl... which would bring
CMake back into the game...
Furthermore not many people are building Curl from sources... I would
say 99% of people consume them via their package manager (dnf, yum, apt
etc.) of their distributions or via flatpak or alike...Who is building
from source today?
So I don't see here the in relationship to Maven... or are we talking
about bootstrapping Maven from source without pre existing Maven/Ant etc. ?
But for Maven 4. I see no problem in upgrading the minimum requirement
to JDK 17 (runtime)... If people can not upgrade (for whatever reason)
they can continue to use Maven 3.X ... Also as I mentioned several times
before even with JDK 17 you can build code for java 7... and if that is
not sufficient you can use Toolchain... (also mentioned several times
before)...
Apart from that if I take that argument in consequence (also mentioned
several times before)... than we have to stop any upgrade in JDK minimum
version and go back to JDK 1.5 or even 1.4 (or even less)...because
there are people using those ancient versions...
Please don't apply our possiblites to others and don't make any assumptions
what others can or cannot do. Rasing to 17 w/o massively rewriting core to
benefit from post-8 constructs a pure lie to ourselves. We cannot even keep
JIRA issue count low. I'd really focus on what really matters.
I have given solutions to solve possible issues... and now I should not
show possible solutions... very interesting...
Why is massively rewriting required? In Maven core (master branch) is
already using a lot of JDK 8 parts.. which can be increased of course,
for example using JDK17 as base line would make it possible to use
sealed classes, records, var usage etc. only to mention a few... of
course that will take time no doubt about that...(mentioned several
times before)...
Also staying on old things (JDK8 is old) will not attract new developers
which is a thing in particular in relationship to the mentioned part
about JIRA issues etc. meaning the number of contributors could be higher...
Which is from my point of view exactly the opposite argument.. upgrade
to most recent JDK 17 at min ... or even JDK 21... to get better
attraction for other possible contributors..
https://www.jetbrains.com/lp/devecosystem-2023/java/
https://www.jetbrains.com/lp/devecosystem-2022/java/
https://www.jetbrains.com/lp/devecosystem-2021/java/
This represents nothing especially not those who aren't or cannot advertise
what thy use. Never trust statistics you haven't falsified yourself.
You should check the
https://www.jetbrains.com/lp/devecosystem-2022/methodology/ etc. That's
available for all given reports. You can get the raw data...
> not those who aren't or cannot advertise what thy use.
If they can not use more recent things they can continue to use Maven
3... (mentioned before).. that contradicts in itself.. described
solutions which work and that should not be shown/mentioned...makes no
sense.
Those statistics mention things like usage of JDK 7, 6 and even 5. What
is the problem here? Only those reports show that the number of the
usage for JDK5,6,7 is very low...not to say extremely low...
Based on which argument do you conclude that we can not to upgrade to
JDK 17 or even to JDK 21: for Maven 4?
1. It needs time to change things in core
2. We would exclude people (discussion about how many?) who can not upgrade.
Answers to them:
1. It has taken time to incorporate changes for JDK 8 in core and
plugins etc.. and it will take time to change more of course.. no doubt
about that.
2. Mentioned solutions for that. (continue to use Maven 3.X; Toolchain).
Are those things a reason not to lift ? No.
Furthermore So that means your own arguments are now contradicted...
Many other tools and libraries and frameworks already did that (Spring
Boot 3(JDK 17), Quarkus(JDK 17), Micronaut (JDK 17) etc., ..... and even
Jakarta EE 11 has set even JDK 21 as baseline...
(https://jakarta.ee/specifications/platform/11/)
Kind regards
Karl Heinz Marbaise
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
