> Where is it maintained? In Central repository? No there does it not
exist.
Who maintains all the other stuff in central? Maven? Obviously not... so
yes it does not exits currently just because there is no support from
maven so there is not much reason to upload/maintain it there...
Also I have a link to JustJ a project that already do maintain such
packages and upload them (just not to central).
> So how to download that JDK ?
Simply as part of the build, e.g. mvn-wrapper downloads maven, so there
are ways to have a minimal bootstrap code that runs on "older" systems
that then gets the required stuff.
> use that to start the build...
I don't talking about the build (as other mentioned modern JVMs are
often available on the developer machine), but for the compile itself
(that's where today a toolchain is used).
> So where to get temurin/corretto/Zulu/Liberica
If there is support, and it works, people will ask other vendors to
upload them to central as well, as with any other library that is on
central today ...
Am 19.07.22 um 21:47 schrieb Karl Heinz Marbaise:
On 19.07.22 20:34, Christoph Läubrich wrote:
> You can use sdkman, jenv or even the OS supports that...
But why should I use other tools if maven can do it in the first place?
> As I wrote before I don't want to pile up another maintenance part on
> the Apache Maven team.. that does not make sense... nor do we have
> enough people here to handle that...
All parts are already there and maintained (e.g. locating and
downloading an artifact),
Where is it maintained? In Central repository? No there does it not exist.
the only missing piece is that the toolchain
manger not only understands how to read toolchain.xml but also use an
artifact declared in the pom is pointing to a (packed) JDK ...
so something like
<dependency>
<groupId>org.openjdk</groupId>
<artifactId>jdk</artifactId>
<version>11.0.2</version>
<type>jdk</type>
</dependency>
So how to download that JDK ? You have to run Maven anyway (or another
tool because it's not in central??) and using a JDK. Or you have to
develop a tool which does not need a JDK... or native compiled tool etc.
So you have to download that, unpack it (somewhere?) and use that to
start the build... consequences for using repo manager / IDE / maybe
other tools to support that ...etc.
So many thing needed to be changed...So where to get
temurin/corretto/Zulu/Liberica just to mention a few or other JDK's from
different vendors etc... ?
so everything is defined in my pom, I can run maven with whatever maven
I like and don't need to tell developers to download version X, run the
build with Y, configure their toolchains and so on...
Use sdkman or alike for the JDK... or OS Based packager..already written.
Am 19.07.22 um 20:27 schrieb Karl Heinz Marbaise:
Hi,
On 19.07.22 20:15, Christoph Läubrich wrote:
Then there should be no issue to move to latest java isn't it?
From my point of view simply no.
Actually using any "external tool" is not really a solution, for the
problem I think, as all hese tools suffer from the fact that they
somehow need to guess from what place to get a condescending version
(in
contrast to a dependency)
You can use sdkman, jenv or even the OS supports that...
linux/MacOS/Windows ...
As I wrote before I don't want to pile up another maintenance part on
the Apache Maven team.. that does not make sense... nor do we have
enough people here to handle that...
Furthermore those tools might need to be improved...
Kind regards
Karl Heinz Marbaise
Am 19.07.22 um 19:35 schrieb Karl Heinz Marbaise:
Hi,
On 19.07.22 19:23, Christoph Läubrich wrote:
> Instead, I think we need to simplify toolchains for users,
I always wondered if it would not be possible to upload an
(open-)jdk to
central and let maven download and use it like it can do with regular
dependency... at laest for Eclipse we have the JustJ project that do
something similar for the "Eclipse IDE World":
To be honest. Simply no for that because there are so many tools which
handle the installation/selection of the JDK very well.. I don't
want to
start another area with big support efforts.
Those problems have already being solved.
Kind regards
Karl Heinz Marbaise
https://www.eclipse.org/justj/
Am 19.07.22 um 18:48 schrieb Tamás Cservenák:
@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).
T
On Tue, Jul 19, 2022 at 6:34 PM Anders Hammar <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>
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
For additional commands, e-mail: dev-h...@maven.apache.org
