On Wed, 20 Jul 2022 at 02:49, Karl Heinz Marbaise wrote:
> Hi,
>
> I really mean runtime ...
>
> Kind regards
> Karl Heinz Marbaise
>
> On 19.07.22 18:28, Tamás Cservenák wrote:
> > Howdy,
> >
> > Running or building?
> >
> > As for building, I am all for it.
> > For running (so the bytecode
> 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
+1
On Wed, 20 Jul 2022 at 00:27, Tamás Cservenák wrote:
> Howdy,
>
> We fixed one regression in install-file Mojo
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINSTALL%20AND%20fixVersion%20%3D%203.0.1
>
> Staged repository:
>
czw., 14 lip 2022 o 23:36 Olivier Lamy napisał(a):
> On Fri, 15 Jul 2022 at 07:30, Olivier Lamy wrote:
>
> >
> >
> > On Thu, 14 Jul 2022 at 19:25, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > wrote:
> >
> >> I don't think that it is a code problem ... in the most times.
> >>
> >> eg:
>
Hi,
On 19.07.22 21:28, Delany wrote:
Elliotte, you make it sound like they don't *want* to upgrade to JDK17. But
who wouldn't want that?
Its usually the business holding that back. If I can tell the business,
sorry, but Maven requires it - then that's the end of the conversation.
They won't
On 19.07.22 20:29, Jorge Solórzano wrote:
On Tue, Jul 19, 2022 at 7:52 PM Karl Heinz Marbaise wrote:
Hi,
On 19.07.22 19:44, Jorge Solórzano wrote:
I really like the idea.
This might also need to go in hand with plugins, the compiler
"release" argument is the way to go and this will require
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
On 19.07.22 21:28, Delany wrote:
What little I know, I appreciate the bold move to JDK17 and I guess
it'll pay off in the long run. Who knows what's next around the corner.
I could tell you: JDK 21 (LTS) in September 2023. Not very far away...
Kind regards
Karl Heinz Marbaise
Elliotte, you make it sound like they don't *want* to upgrade to JDK17. But
who wouldn't want that?
Its usually the business holding that back. If I can tell the business,
sorry, but Maven requires it - then that's the end of the conversation.
They won't argue. Switching to another build system to
Hi,
On 19.07.22 20:38, Elliotte Rusty Harold wrote:
On Tue, Jul 19, 2022 at 12:25 PM Karl Heinz Marbaise 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 ?
Bluntly, its an
On Tue, Jul 19, 2022 at 12:25 PM Karl Heinz Marbaise
wrote:
> Hi to all,
>
> what do you think about using JDK17 as minimum requirement for running
> the future Apache Maven 4.0.0 ?
>
Bluntly, its an atrocious idea that work would likely lead to forks of
maven or a lot of projects abandoning
> 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
On Tue, Jul 19, 2022 at 7:52 PM Karl Heinz Marbaise wrote:
>
> Hi,
>
> On 19.07.22 19:44, Jorge Solórzano wrote:
> > I really like the idea.
> >
> > This might also need to go in hand with plugins, the compiler
> > "release" argument is the way to go and this will require removing
> > completely
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
Then there should be no issue to move to latest java isn't it?
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
Let's do this for start.
Just "tone down" it.
T
On Wed, Jul 13, 2022, 20:04 Slawomir Jaranowski
wrote:
> Hi,
>
> To summarize the discussion we have many votes to go this way.
>
> My proposition is as first step remove windows nodes from jenkins builds, I
> see many fals positive fails on
Hi,
On 19.07.22 19:44, Jorge Solórzano wrote:
I really like the idea.
This might also need to go in hand with plugins, the compiler
"release" argument is the way to go and this will require removing
completely the maven.compiler.source and maven.compiler.target.
No they should not removed
I really like the idea.
This might also need to go in hand with plugins, the compiler
"release" argument is the way to go and this will require removing
completely the maven.compiler.source and maven.compiler.target.
Compiling to an older release is the easy part, yet the only thing
that might
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
Am 2022-07-19 um 19:30 schrieb Sylwester Lachiewicz:
I would say - it depends how many Maven versions we plan to have before.
We have 3.9 with Java 8 baseline, then 3.10 - 11, so definitely 4.0 could
have 17
No, 3.9 is a prep for 4.0. There won't be 3.10. We don't even have
resources to make
Hi,
On 19.07.22 19:17, Hilco Wijbenga wrote:
On Tue, Jul 19, 2022 at 10:15 AM Karl Heinz Marbaise wrote:
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
I would say - it depends how many Maven versions we plan to have before.
We have 3.9 with Java 8 baseline, then 3.10 - 11, so definitely 4.0 could
have 17
Sylwester
wt., 19 lip 2022, 18:25 użytkownik Karl Heinz Marbaise
napisał:
> Hi to all,
>
> what do you think about using JDK17 as minimum
> 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
On Tue, Jul 19, 2022 at 10:15 AM Karl Heinz Marbaise wrote:
> 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
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
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)
- use toolchains to target any other Java (older or "specific")
T
On Tue, Jul 19, 2022 at 7:03 PM Karl Heinz
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,
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,
Hi,
On 19.07.22 18:34, Anders Hammar 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.
I see several options to improve the code:
* sealed-class which makes it
Hi,
I really mean runtime ...
Kind regards
Karl Heinz Marbaise
On 19.07.22 18:28, Tamás Cservenák wrote:
Howdy,
Running or building?
As for building, I am all for it.
For running (so the bytecode level of built Maven artifacts) may be "too
soon" IMHO, I am unsure about this.
Spring
@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
Am 2022-07-19 um 18:24 schrieb Karl Heinz Marbaise:
Hi to all,
what do you think about using JDK17 as minimum requirement for running
the future Apache Maven 4.0.0 ?
Given that 8 is a transitional version, I guess 8 is still good enough.
I cannot see any benefit in Java 8, frankly, that
Am 2022-07-19 um 16:26 schrieb Tamás Cservenák:
Howdy,
We fixed one regression in install-file Mojo
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINSTALL%20AND%20fixVersion%20%3D%203.0.1
Staged repository:
https://repository.apache.org/content/repositories/maven-1784
Source
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
Howdy,
Running or building?
As for building, I am all for it.
For running (so the bytecode level of built Maven artifacts) may be "too
soon" IMHO, I am unsure about this.
Hence, I'd go with enforcer to require JDK17, but use compiler release=11
for now.
Note: key component, like sisu inject
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
Hi,
+1 from me.
Kind regards
Karl Heinz Marbaise
On 19.07.22 16:26, Tamás Cservenák wrote:
Howdy,
We fixed one regression in install-file Mojo
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINSTALL%20AND%20fixVersion%20%3D%203.0.1
Staged repository:
Howdy,
We fixed one regression in install-file Mojo
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINSTALL%20AND%20fixVersion%20%3D%203.0.1
Staged repository:
https://repository.apache.org/content/repositories/maven-1784
Source release SHA512:
Howdy,
The Apache Maven team is pleased to announce the release of
Maven Deploy Plugin 3.0.0.
Plugin is Java7 level and compatible with Maven 3.2.5+
Site: https://maven.apache.org/plugins/maven-deploy-plugin/
Release Notes - Maven Deploy Plugin - Version 3.0.0
** Bug
* [MDEPLOY-193] -
Howdy,
The Apache Maven team is pleased to announce the release of
Maven Install Plugin 3.0.0.
Plugin is Java7 level and compatible with Maven 3.2.5+
Site: https://maven.apache.org/plugins/maven-install-plugin/
===
NOTE: Release 3.0.0 has a regression related to install-file Mojo that
slipped
Howdy,
The Apache Maven team is pleased to announce the release of
Maven Indexer 6.2.2.
Site: https://maven.apache.org/maven-indexer/
Release Notes - Maven Indexer - Version 6.2.2
** Bug
* [MINDEXER-164] - IndexOutOfBoundsException during indexing of
repositories files
Have fun
- The
Howdy,
The vote has passed with the following result:
+1 : Michael, Karl-Heinz, Romain, Guillaume and me
-1 : Václav (nb)
PMC quorum: reached
I will promote the source release zip file to Apache distribution area and
the artifacts to the central repo.
Thanks
T
Howdy,
The vote has passed with the following result:
+1 : Michael, Karl-Heinz, Romain, Guillaume
PMC quorum: reached
I will promote the source release zip file to Apache distribution area and
the artifacts to the central repo.
Thanks
T
Howdy,
The vote has passed with the following result:
+1 : Sylwester, Michael, Guillaume, Slawomir, Karl-Heinz and me
PMC quorum: reached
I will promote the source release zip file to Apache distribution area and
the artifacts to the central repo.
Thanks
T
Hi,
+1 from me.
Kind regards
Karl Heinz Marbaise
On 16.07.22 18:00, Tamás Cservenák wrote:
Howdy,
We fixed one bug:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINDEXER%20AND%20fixVersion%20%3D%206.2.2
Staged repository:
+1
sob., 16 lip 2022 o 18:00 Tamás Cservenák napisał(a):
> Howdy,
>
> We fixed one bug:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINDEXER%20AND%20fixVersion%20%3D%206.2.2
>
> Staged repository:
> https://repository.apache.org/content/repositories/maven-1778/
>
> Source
I have a GraphBuilder component as a core-extension that works well
since a while.
No I like to require another component but that component fails with:
"No implementation for org.apache.maven.plugin.LegacySupport was bound"
So my first guess was that this might be to early... but if I inject
47 matches
Mail list logo
