Welcome to the latest OpenJDK Quality Outreach update!
The first JDK 22 Release Candidates builds are now available [1]. At this
stage, only P1 issues will still be evaluated. And with the JDK 22 General
Availability set for March 19th, it is now time to fully focus on JDK 23. At
the time of
Hello to all users, contributors and Committers!
The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code Asia 2024 are now
open!
We will be supporting Community over Code Asia, Hangzhou, China
July 26th - 28th, 2024.
TAC exists
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,
The vote has passed with the following result:
+1 : Romain Manni-Bucau, zhongming hua, Guillaume Nodet, Tamás Cservenák,
Benjamin Marwell, Sylwester Lachiewicz, Slawomir Jaranowski, Karl Heinz
Marbaise, Olivier Lamy
-1: Elliotte Rusty Harold
PMC quorum reached
I will promote the source
Howdy,
I intentionally used "Maven" here, and not "Maven 4" as I am sure the
majority of Maven users do not run Maven on the same Java version they
target with their build. We do not do that either.
Some snippets from Herve (who is the ONLY one doing reproducible checks,
kudos for that) votes:
The Apache Maven team is pleased to announce the release of the Apache Maven
Shade Plugin, version 3.5.2
This plugin provides the capability to package the artifact in an uber-jar,
including its dependencies and to shade - i.e. rename - the packages of some
of the dependencies.
> I am sure the majority of Maven users do not run Maven on the same Java
version they target with their build.
Do you use that and the following figures to do a biased conclusion?
"If people don't use the same version then we can higher the version"?
I think we need to consider two things:
*
Romain,
you immediately revealed your WHY:
Take off your "paid dev" hat, and please try again.
We ARE an open source project.
So it IS about us, the volunteers.
Is not about THEM, downstream users.
As it was told a million times:
if they are stuck (due whatever policy or who knows what), they
Hi Hervé,
+1000 on the philosophy!
On the toolchain support I still fail to see why maven has toolchain
anywhere in its code.
Look it how it is used:
* Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
JAVAEA_HOME or alike)
* Most plugins able to switch the JDK can switch the
> So it IS about us, the volunteers.
> Is not about THEM, downstream users.
Not for me, for me and anything ASF is 100% about users and 0% about doers.
Anything not aligned on that should stay a personal github project for me.
> if they are stuck (due whatever policy or who knows what), they can
for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have to
update our plans https://maven.apache.org/developers/compatibility-plan.html
the approach I'd love to promote is "what do we require to not hurt our
diversity of users when upgrading minimum prerequisites" (and I'm
Its more about supporting an ancient JVM/JDK than compiling Maven on an
ancient version. So as long as Maven targets 8 or less in its build, I don't
think anyone cares (at least I don't) what the actual version of the JDK you
use in the build pipeline. Go ahead and have a source setting of
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
I’ve been wondering for some time… My uninformed impression is that most
corporate development uses Eclipse or IntilliJ, which I believe run only on the
java version they come packaged with, which presumably is not usually the
target java version for the code being developed. Aside from
IDEs, including the 2 you named, have a configuration system for multiple
JDKs. This allows devs to build for multiple versions of the JVM. Likewise,
Maven has multiple ways to configure multiple JDKs for use by different phases
or plugins used in a given compilation setup and to target
From your first paragraph I’d guess you would be on the “maven built on a
recent LTS java” side. I was wondering, given these omnipresent IDES, and
possibly from a philosophical perspective, what the arguments for “maven built
on an antique JVM” would be.
Thanks
David Jencks
> On Feb 20,
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
I think I mentioned it elsewhere but the fact that maven requires Java
to run is actually a (sometimes annoying) implementation detail, so if
maven would simply ship with a (stripped) JVM, being a native binary or
actually would probably resolve some problems in the area of java
discussions.
18 matches
Mail list logo
