actually if it can, just upgrading to 17 seems a good idea...
as spring's latest is for 17, maybe we can join forces to make the market
to 17...
(however I somehow love fiber so if people wanna 21 I just well be
happy)
I always think toolchains shall not be somehow public slaves for every
You are not the only one who hates jigsaw.
As a real joke, about 4-6 years ago in a jackson mailing list, an [oracle
employee] ask for them to delete module-info in the jars to make it
runnable at lower jdk version, so yes even people in oracle (at least one)
seems don't really agree with
Howdy,
I think we want a vote about this, plus, Resolver is picking up the latest
Java features. So we ("movers") even have arguments why we need new Java
versions.
I wonder what "aligners" (those who want the same Java version to run Maven
and run their end product built by Maven, in other words
Hi folks,
Wanted to offer an one 'end user' data point. For transparency, I run Java
engineering at Microsoft (including supporting Minecraft and LinkedIn
subsidiaries). We're one of the Big Tech Co's that have moved 90%+ of their
Java workloads off Java 8 onto 11+ :-).
I acknowledge we're not
The JVM and JRE don't let you escape out of JPMS. Presumably this is why we
had to redo a bunch of Maven modules for Log4j on the master branch
(unreleased WIP for 3.0).
Gary
On Tue, Feb 6, 2024, 6:43 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> Le 2024-02-07 à 00 h 37,
Le 2024-02-07 à 00 h 37, Gary Gregory a écrit :
I have no use for JPMS today, I just don't want it to get in the way,
which is impossible since there is no --dont-bother-me-jpms flag...
That option exists at the level of the proposed Maven 4 API and has a
JUnit test [1]. Plugins have the
I have no use for JPMS today, I just don't want it to get in the way, which
is impossible since there is no --dont-bother-me-jpms flag...
Gary
On Tue, Feb 6, 2024, 6:34 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> Hello
>
> Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit
Hello
Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit :
Nobody wants Jigsaw and the API improvements aren't enough to get
people to upgrade.
I cannot debate on whether a small minority, or a big minority, or a
majority of developers want JPMS (a.k.a. Jigsaw), because I have no data
for
Scala has lousy support and the language is dying mainly because Scala3 seems
like a Kotlin clone (with poor support). The folks that run Scala are
academics and it shows in their marketing and mismanagement of the language.
However, Kotlin is growing and it would be very surprising for me
> Security issues. LTS support is a thing, and not just for JDKs.
Customers really, really want versions of tools and libraries they
don't have to upgrade, but that are supported when something does come
up. And when a security issue does come up, they want a drop in
replacement that fixes that
Le mar. 6 févr. 2024 à 16:12, Hunter C Payne
a écrit :
> There are also license differences between Java 8 and Java 9+. And the
> improvements beyond 8 are not things the market seems to want. Nobody
> wants Jigsaw and the API improvements aren't enough to get people to
> upgrade. Those that
There are also license differences between Java 8 and Java 9+. And the
improvements beyond 8 are not things the market seems to want. Nobody wants
Jigsaw and the API improvements aren't enough to get people to upgrade. Those
that really want new language features use Scala or Kotlin and
While I don't think google-http-java-client is something we can rely on to
decide anything for us for the 10 coming years, similarly not sure that
mono-repo in big companies is actually a thing we should consider as a
first citizen, in particular after the drawbacks big companies got trying
to
Eliotte,
You are missing the topic of this whole thread.
What you wrote in any of your mails is totally unrelated to the thread.
I do feel sorry, or unsure, maybe sympathize with your work issues and
difficulties, but I still cannot understand what all that has to do with
the ASF Maven Project?
On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell wrote:
>
> Besides that, most big (tech) companies do not allow unmaintained or
> unsupported software.
How I wish that were true. Unmaintained and unsupported software is
all over the place, in big tech, little tech, enterprise, and my
mother's
On Tue, Feb 6, 2024 at 12:00 PM Tamás Cservenák wrote:
>
> Howdy,
>
> For start, I think Martin assumed the "build time Java requirement for
> Maven4"?
>
> If so, my "vote" would be like:
> * build time: "latest LTS" (fixed at the moment when 4.0.0 GA happens,
> until then we just follow LTS),
I'm interested, how do I become a customer of "apache-maven", I'm not
aware of such thing anyways there are some options:
1) Fork and fix that bug and deploy a new version to your
company-artifact server for the version you are using (maven central is
not a requirement for maven dependencies)
On Tue, Feb 6, 2024 at 10:50 AM Kévin Buntrock wrote:
>
> From my modest point of view : glued to old stack projects do not move at
> all. Why move to a new maven version if the one used works?
>
Security issues. LTS support is a thing, and not just for JDKs.
Customers really, really want
On Tue, Feb 6, 2024 at 8:01 AM Benjamin Marwell wrote:
>
> > we need to think about companies
> that pay for old JDK support
>
> There was a suggestion on slack that companies could provide "dev and
> release manager" for Maven 3 and manage the JDK 8 Maven 3 until they lose
> interest. This
I like all 5 cents
Gary
On Tue, Feb 6, 2024, 7:00 AM Tamás Cservenák wrote:
> Howdy,
>
> For start, I think Martin assumed the "build time Java requirement for
> Maven4"?
>
> If so, my "vote" would be like:
> * build time: "latest LTS" (fixed at the moment when 4.0.0 GA happens,
> until then
Howdy,
For start, I think Martin assumed the "build time Java requirement for
Maven4"?
If so, my "vote" would be like:
* build time: "latest LTS" (fixed at the moment when 4.0.0 GA happens,
until then we just follow LTS), post GA "we adjust to latest LTS on each
minor release (so 4.1, 4.2, etc)"
Personnaly (take it as a vote), I find this a good idea to say:
- 3.x: jdk 8 (whatever someone wants to release some fixes)
- 4.x: jdk 17
On Tue, 6 Feb 2024 at 20:50, Kévin Buntrock wrote:
>
> From my modest point of view : glued to old stack projects do not move at
> all. Why move to a new
>From my modest point of view : glued to old stack projects do not move at
all. Why move to a new maven version if the one used works?
Furthermore, I'm quite impressed by the number of projects starting in java
21 for clients I was considering really shy new adopters. Java 21 is here,
works well,
> we need to think about companies
that pay for old JDK support
There was a suggestion on slack that companies could provide "dev and
release manager" for Maven 3 and manage the JDK 8 Maven 3 until they lose
interest. This already works well for other projects.
Even if no one stands up for
well I just doubt.
From: Xeno Amess
Sent: Tuesday, February 6, 2024 12:18:42 PM
To: Maven Developers List
Subject: Re: Java version for Maven 4?
well nothing affensive but do any guys got any payments from those still-java-6
companies for maintaining maven
well nothing affensive but do any guys got any payments from those still-java-6
companies for maintaining maven for them？
From: Gary Gregory
Sent: Tuesday, February 6, 2024 6:14:32 AM
To: Maven Developers List
Subject: Re: Java version for Maven 4
An interesting question for me is whether we need to think about companies
that pay for old JDK support and how that affects our support for these old
JDKs.
Gary
On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold
wrote:
> On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau
> wrote:
> >
> > Hi
On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau wrote:
>
> Hi Elliotte,
> Java 11 support is already EOL for most vendor until you go "premium"
> flavor which will likely be very few people and most of them will be able
> to pay somebody to backport the needed stuff in custom distro of their
> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new
Howdy,
and sorry, I could not hold my breath...
Basically, you talk about some project somewhere that has been built with
Maven3 for the past 10 years. Fine: You can continue building it using the
same Maven3 for another 10 years, nothing stops you. But I see really
nothing, but really nothing
Hi Elliotte,
While I share the wish 1 repo = 1 JDK, I have a hard time to see how any
company - including the ones you cite - can seriously bet on Java 11 today
for the future (not saying it wasnt hard to reach Java 11 today but we are
discussing on what we'll do tomorrow) and why it would
Based on my experience, I think we (FOSS developers) can create our own
momentum by "simply" creating an EOL schedule. I have seen this EOL aspect
motivate the move away from Jetty 9 for example. Since Maven 4 is not out,
there is nothing to EOL in Maven 3 land unless you want to say that only
On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell wrote:
> Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> no advantage of going to 11:
>
The advantage of going with 11 instead of 17 is that at least 2 really
big tech companies I could name (and who you can probably guess
Those who need Java 8 to *run* Maven will probably not upgrade to
Maven 4 anyway, as their builds will have other problems preventing
them from upgrading.
A few third-party plugins already moved to Java 11+, thinking of spotless.
That said:
+1 Stick with 8 for Maven 3.9.x and maybe a 3.10.x (not
I vote for kill jdk8 out as to force them upgrade to 11+
From: Tamás Cservenák
Sent: Sunday, February 4, 2024 10:35:55 PM
To: Maven Developers List
Subject: Re: Java version for Maven 4?
Howdy,
See Inline.
On Sun, Feb 4, 2024 at 3:01 PM Elliotte Rusty Harold
Howdy,
See Inline.
On Sun, Feb 4, 2024 at 3:01 PM Elliotte Rusty Harold
wrote:
> I can live with Java 11 if I have to, though I really don't see the
> point. Anything past Java 11 ranges from a major hassle to blocker for
> corporate developers, including those at big tech companies like Meta
FWIW, I work for a large company and our business unit just switched to
Java 17 after eons on Java 8. I think requiring Java 17 or 21 to run Maven
is fine. The existing tooling supports generating Java 8 binaries for those
who need it.
Gary
On Sun, Feb 4, 2024, 9:01 AM Elliotte Rusty Harold
If we're actually voting
+1 for Java 8
-1 for Java 17 or any later version.
I can live with Java 11 if I have to, though I really don't see the
point. Anything past Java 11 ranges from a major hassle to blocker for
corporate developers, including those at big tech companies like Meta
and Google,
If maven itself can (and want) to stick to older java versions, can then
please this one kindly be considered:
https://issues.apache.org/jira/browse/MNG-8040
for example the tycho-maven-plugin (and probably others as well) the
issue is that *dependencies* of the project have moved to higher
Side note: dont think toolchain enhancements is a requirement at all, lot
of users keep rejecting this additional work (and to be honest I can agree
1nd it does not help more things than using properties to switch the
env/executable in plugins) so only question for me is the baseline and
minimum
Similarly, this topic (to me at least) somewhat correlates with another
"wrong reflex" (that somehow get roots in project):
- compile against maven-core 3.2.5
- compile with Java 8+ "as we support Maven on Java 8"
Funnily, both are from 2014, just 10 years old.
IMHO,
We SHOULD compile against the
The non problems:
- members building project with ancient java versions and calling -1 on
release votes (as turns out,by mistake)
- javadoc inconsistencies: what is allowed and what not
- being stuck in a 20 year tech stack
...
Again, _build time requirement_ has nothing to do with _runtime
Le 2024-02-03 à 16 h 25, Michael Osipov a écrit :
I still don't understand what non-problem you are trying to solve
here?! I think that your time and our time would be better invested in
solving real problems, just look into JIRA how many issues have piled up.
For the Java version topic, it
Am 2024-02-03 um 15:16 schrieb Martin Desruisseaux:
Hello
From the replies in this thread, it seems to me that there is a
consensus for moving Maven 4 to some Java version after 8. I see:
* 0 in favour of Java 11
* 1.5 in favour of Java 17 (the .5 is because I split a vote between
Before actually changing the runtime requirement, I’d like to make sure we
have good enough support for toolchains on the dev side and in CI (Jenkins,
GitHub actions…).
On the dev side, I once proposed to have an easy integration with sdkman, I
think I did raise a PR for that months ago…
Hello
From the replies in this thread, it seems to me that there is a
consensus for moving Maven 4 to some Java version after 8. I see:
* 0 in favour of Java 11
* 1.5 in favour of Java 17 (the .5 is because I split a vote between
Java 17 and 21)
* 2.5 in favour of Java 21
* 4 seem
I'm close to Ben and Manfred,
I think Maven can get a lot of value (for maintaining as for runtime) by
switching to Maven 21 a base for itself.
Matthias
Am 22.01.2024 um 13:33 schrieb Benjamin Marwell:
To add some more information, I have seen some extreme reduction in
build times after
Le lun. 22 janv. 2024 à 09:52, Hervé Boutemy a écrit :
>
> Le dimanche 21 janvier 2024, 22:03:59 CET Guillaume Nodet a écrit :
> > At build time, I think it's fine to bump to whatever is needed to make
> > our life manageable. If 17 is required, so be it.
> +1
>
> my biggest concern with Maven 4
I agree with observations ... in the Trino project we switched to
require Java 17 ages ago and now switched to 21 for the project itself.
The language improvements to 17 and then to 21 allow for a lot of code
improvements on the source level.
As a build tool that supports building other
Le lun. 22 janv. 2024 à 13:34, Benjamin Marwell a
écrit :
> To add some more information, I have seen some extreme reduction in
> build times after switching from Java 11 to 17 or even 21 (just for
> build, not the runtime).
> We can still verify it runs on 11/17 by using the integration tests,
To add some more information, I have seen some extreme reduction in
build times after switching from Java 11 to 17 or even 21 (just for
build, not the runtime).
We can still verify it runs on 11/17 by using the integration tests,
but having the (possibly parallel) unit- and integration tests
Definitely the improvement is targeting Maven 4 API, hence only plugins
using Maven 4 API would benefit from it.
Backporting this to Maven 3 is nearly impossible.
Basically what we have in Maven 3 (and related plugins, that fiddle with
classpath/modulepath) is what we stay with in Maven 3
Le 2024-01-22 à 09 h 52, Hervé Boutemy a écrit :
are there known features in Maven 4 API not available in Maven 3 that
would bring stronger interest in writing a goal for Maven 4?
If accepted, the way to determine where to put dependencies (class-path,
module-path, etc.) would require Maven
Le dimanche 21 janvier 2024, 22:03:59 CET Guillaume Nodet a écrit :
> At build time, I think it's fine to bump to whatever is needed to make
> our life manageable. If 17 is required, so be it.
+1
my biggest concern with Maven 4 is not JDK runtime requirement, but plugins
future when a plugin
Same there while surefire/invoker runs respect supported versions.
Le dim. 21 janv. 2024 à 22:04, Guillaume Nodet a écrit :
> At build time, I think it's fine to bump to whatever is needed to make
> our life manageable. If 17 is required, so be it.
>
> Guillaume
>
> Le sam. 20 janv. 2024 à
At build time, I think it's fine to bump to whatever is needed to make
our life manageable. If 17 is required, so be it.
Guillaume
Le sam. 20 janv. 2024 à 19:18, Martin Desruisseaux
a écrit :
>
> Hello
>
> I would like a little clarification about the Java version for Maven 4.
> I saw debate on
Howdy,
Maven master (home of Maven 4) is currently Java 8 level.
But many of us agreed that if someone needs Java 8 (or even below), they
can use Maven 3.x (3.9.x or 3.8.x even). Those two are pretty much in
"bugfix" mode, dormant, but not dead.
Personally, if we are about to move, I'd not move
57 matches
Mail list logo
