I think this difference during Maven build between compile time JDK vs tests
execution time JDK is key for normal users choice. And ease of setup if
multiple JDKs are involved (= it's not easy to have configured prerequisites in
place)
I suppose good articles showing the full setup to do so
*Just for the record*.
Toolchain has a great use case IMHO: enable to run on multiple jdk the same
plugin (think surefire/failsafe for ex) without any matrix or CI trick.
The big plus: you test the code runs with all versions you need against the
same binary without side effects. Sometimes it is
it's not about *one not wanting* to upgrade (anybody can use JDK 17 if they
want currently)
it's about *one forcing everybody else* to upgrade (and enter the toolchain
setup question)
I'd be curious to see what will happen the day one of the base plugin force to
upgrade:
You need toolchains if your code needs the JAXB classes removed in JDK11.
Delany
On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:
> To get this discussion a bit more back to actual substance:
>
> Do you still need toolchains with JDK 11/17? I set the
Toolchains is not needed. Many plugins don't even support it. However, the
'release' flag only checks stuff in java itself as well as your codes direct
usage. It doesn't look in the libraries you use indirectly. For that you need
the enforcer plugin to look at the byte code. Trust the cross
Uhm, I have definitely gotten pushback when I ported some changes back to
the 3.8.x branch. The wording was (paraphrasing) "maven 3.8 is dead and we
do not plan to do any further releases, so don't add code to it". This was
with Maven 3.8.4 :-)
-h
On Wed, May 31, 2023 at 3:37 AM Guillaume
Agreed, that is one way to do that, but it seems to me that this is a
CI/integration test issue, not a build issue per se.
We do the same thing in Jdbi: Build with the LTS JDK, then test against 8,
11, 17, current Java release:
https://github.com/jdbi/jdbi/blob/master/.github/workflows/ci.yml
I always assumed that Java versions are a solved problem in JDK 9+ with
'-release' which creates bytecode for the targeted JDK and even ensures
that no classes or methods from the JDK are used that are not supported in
that version.
There is a desire for "everything must be the same" that I am
To get this discussion a bit more back to actual substance:
Do you still need toolchains with JDK 11/17? I set the release version to
"8" (or anything else) in my builds, ripped out all the toolchains and it
"just works". We have done this for Jdbi for ages (require Java 11+ as the
build JDK; we
I have to strongly disagree. If Maven wants to remain relevant it needs
to be using a relatively modern JDK and language that is available to
open source developers and interesting to work on.
Nobody wants to work on Java 8 code.
Ultimately the committers and project maintainers can vote and
Other projects have tried to do that (given they are different types of
projects) and it turned out that keeping JVM8 support going when not compiling
on JDK8 proved difficult and when push came to shove, it was JVM 8 support that
was dropped. I know that's not you or this project, but human
+1
Jira report is not complete - contains 2 issues, but release notes has 4
https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/jira-report.html
sob., 3 cze 2023 o 15:10 Michael Osipov napisał(a):
> Hi,
>
> we solved 4 issues:
>
>
Your inclination to ignore points of the debate doesn't do your own
arguments any justice.
Multiple times it's been explained that raising the required runtime JDK in
Maven 4 will not prevent you from
- building with a lower JDK (via toolchains)
- targeting a lower JDK (via the release property)
-
Hunter, a language done for java (think mojo, no real choice to zmbrace
bytecode ecosystem) which is growing is java...scala is dead, groovy dont
grow anymore and kotlin kind of stopped too so maybe you do it everydays as
some people but ecosystem is clearly not on that side. This part is not
I don't care about the threads. They are fine with me. I care about the
amount of ceremony that you create that eats into developer time. If you
want to do it for yourself: feel free to do so. It is your time after all.
But you and others then turn around and say "everyone now needs to do what
I
Ok, so let's take these points one at a time:* Reduce build matrix, save
energySo, less builds which is good but pretty minimal value.
* Attract devsAbsolutely not. If you want to attract devs, switch to a
language that is actually growing (no I'm advocating for this). That isn't
Java. If
Seems people missed this (somewhat related) thread:
https://lists.apache.org/thread/kpsrb28nst84vtohwngy3140g1r0ydd4
Thanks
On Mon, Jun 5, 2023, 20:40 Hunter C Payne
wrote:
> Hi, Karl, I'm not sure I agree you have "stated a benefit" so far.
> There have been plenty of hand-wavy arguments
Ok, here's a benefit of Java 11/17 or two:
* Reduce build matrix, save energy
* Attract devs
* CDS for non-OpenJ9-users
* Better clarity of code (yes, I mean that)
* No additional work (we don't need to migrate, just use the features when
modifying a line for a bug/feature anyway)
* We leave no
Hi, Karl, I'm not sure I agree you have "stated a benefit" so far. There
have been plenty of hand-wavy arguments but nothing really solid. That's why
you are getting so much push back. Point to a specific feature you need or
some other thing that would help the project in some significant
You are receiving this message because you are subscribed to one more
more developer mailing lists at the Apache Software Foundation.
The call for presentations is now open at
"https://apachecon.com/acasia2023/cfp.html;, and will be closed by
Sunday, Jun 18th, 2023 11:59 PM GMT.
The event will
Hi,
On 03.06.23 11:46, Hervé Boutemy wrote:
+1
I really don't what benefit we get from going to Java 17
which was already part of the email:
> Based on the argument we don't need features of JDK17+ I see a number
> of things which could make our handling/maintenance easier for example
>
On 05.06.23 13:55, Romain Manni-Bucau wrote:
Hi
Le lun. 5 juin 2023 à 13:22, Elliotte Rusty Harold a
écrit :
On Sun, Jun 4, 2023 at 10:59 AM Delany wrote:
I think the point I'm making is no-one wants to write in an older version
of the language they started writing in. Its tedious.
Hi,
On 05.06.23 13:21, Elliotte Rusty Harold wrote:
On Sun, Jun 4, 2023 at 10:59 AM Delany wrote:
I think the point I'm making is no-one wants to write in an older version
of the language they started writing in. Its tedious. Anyone who started
writing java11 code is going to have a hard
I'm having trouble reading this email, hang on, let me adjust the rabbit
ears on my black and white television... ah better now. I'm sorry what were
you saying? :-)
Gary
On Mon, Jun 5, 2023, 07:22 Elliotte Rusty Harold wrote:
> On Sun, Jun 4, 2023 at 10:59 AM Delany wrote:
> >
> > I think the
Hi
Le lun. 5 juin 2023 à 13:22, Elliotte Rusty Harold a
écrit :
> On Sun, Jun 4, 2023 at 10:59 AM Delany wrote:
> >
> > I think the point I'm making is no-one wants to write in an older version
> > of the language they started writing in. Its tedious. Anyone who started
> > writing java11
On Sun, Jun 4, 2023 at 10:59 AM Delany wrote:
>
> I think the point I'm making is no-one wants to write in an older version
> of the language they started writing in. Its tedious. Anyone who started
> writing java11 code is going to have a hard time accepting they need to
> write in java8, just
26 matches
Mail list logo
