Hi,

On 19.07.22 19:10, Tamás Cservenák wrote:
Actually, yes, I keep forgetting about release flag: so, if running on
LTS, user can do:
- use compiler "release" flag to target any Java from 8 to 17 (up to
current LTS it runs on)

You can build for target JDK 7 with JDK17 via --release ...
and also not ONLY on LTS release of JDK you can use also non LTS
versions for that...

Kind regards
Karl Heinz Marbaise

- use toolchains to target any other Java (older or "specific")

T

On Tue, Jul 19, 2022 at 7:03 PM Karl Heinz Marbaise <khmarba...@gmx.de
<mailto:khmarba...@gmx.de>> wrote:

    Hi,

    On 19.07.22 18:48, Tamás Cservenák wrote:
     > @Anders I'd stop using the "run on for what you build for"
    aspect. We will
     > have to split it IMHO. It caused a lot of luggage for us in the
    past (we
     > still release Java 7 plugins in 2022).
     >
     > Instead, I think we need to simplify toolchains for users, and
    make it
     > clear for them that for their benefit (but also ours), they
    should use the
     > latest LTS whatever they target for. Running the latest LTS has
    way too
     > many benefits for us as for users (faster, less resource, better
    errors
     > [reported to us] and so on). Workstations are usually fully up to
    date
     > (latest OS, latest Java, latest Maven), so we will somehow have
    to "trick"
     > (persuade) users to stop what they did before (if they targeted
    some legacy
     > system running on Java7): they installed Java7 and run Maven
    using it, and
     > do it differently. Just like IDEs, they clearly separate
    "runtime" Java
     > (they usually "bring their own") and "target" Java, and the two
    are two
     > completely separate things.
     >
     > Now, all this above is "just me" (my personal opinion). After
    all, we may
     > consider making toolchains "less pain" (as you say "it adds
    complexity"),
     > so maybe some integration with macOS libexec/java_home, sdkman, jenv,
     > etc... (unsure what or how yet, am just throwing out ideas).

    I'm on MacOS ... no it simply works using --release...

    Much easier than toolchains.

    Kind regards
    Karl Heinz Marbaise
     >
     > T
     >
     > On Tue, Jul 19, 2022 at 6:34 PM Anders Hammar <and...@hammar.net
    <mailto:and...@hammar.net>> wrote:
     >
     >> I'd say Java 11 if there isn't some very good feature in Java 17
    that we
     >> need. So far we have supported the current and prior Java LTS
    version and I
     >> think that's a good aim. Lot's of users are still on Java 11 and
    even if
     >> you can execute Maven with a different Java version than you
    build for, it
     >> does add some complexity.
     >> But, if we don't release it until Sept 2023 I think Java 17 is
    fine (as
     >> Java 23 should be out). :-)
     >>
     >> On Tue, Jul 19, 2022 at 6:24 PM Karl Heinz Marbaise
    <khmarba...@gmx.de <mailto:khmarba...@gmx.de>>
     >> wrote:
     >>
     >>> Hi to all,
     >>>
     >>> what do you think about using JDK17 as minimum requirement for
    running
     >>> the future Apache Maven 4.0.0 ?
     >>>
     >>> Kind regards
     >>> Karl Heinz Marbaise
     >>>
     >>>
    ---------------------------------------------------------------------
     >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
    <mailto:dev-unsubscr...@maven.apache.org>
     >>> For additional commands, e-mail: dev-h...@maven.apache.org
    <mailto:dev-h...@maven.apache.org>
     >>>
     >>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to