Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Romain Manni-Bucau 
Le sam. 23 juil. 2022 à 21:05, Enno Thieleke 
a écrit :

> Fwiw:
>
> Romain, I think you're exaggerating. The answer is, like in most cases:
> "it depends".
>
> Most people, we're most likely talking 95-99% here, will happily use JDK
> 17 with Maven 4.
>

I would lower the figure - keep in mind 95-99% of people also uses libs and
are affected by what I described - but agree "most" would see it...at the
cost of configuring toolchain and even just the test/compiler version in
the pom which breaks our convention over config core design IMHO.

So until we change our design to isolate all our core code and mojo run
from contextual java version (most mojo are not toolchain friendly, this
requires a mojo executor evolution to make the ecosystem functional), and
likely means we can:

1. Have background jvm runners (reusable) to avoid the cold perf pitfall of
toolchain
2. Toolchain functional for all mojo without any mojo change
3. A global property to limit the configuration for all mojo

I dont think it would work well in practise.

I also dont want to exclude 50% of users (8+11) just cause we think we
would maybe gain from that - there is very few valid reason in terms of
compilation to do that on our side.

Side note: technically, if reached, it means we can make mvn a native
binary with graalvm and run mojo in java runner so java wouldnt be a real
constraint for us/users but this has high impacts in terms of design and
code update requirements.


> Some people might need to compile for lower sources and targets, but
> running tests for those builds in JDK 17 instead of, let's say 11, _will
> suffice in most cases_.
>
> Yes, there will be edge cases where people will be forced to use different
> JDKs at least for tests, some even for builds. But that's possible, so they
> won't get left behind.
>
> Regarding mvnd: It's not a silver bullet. It never was and it never will
> be. Whenever a build spawns new JVMs (for tests or other tasks), it doesn't
> benefit from mvnd anymore (in as much as it would without spawning new
> JVMs).
>
> To not use the latest (LTS) JDK in order to "better" support the 1-5% of
> the Maven users, who're still using obsolete JVMs (I'm obviously referring
> to Karl's assumption, which I agree with), would be a kick in the teeth of
> all Maven developers, who finally want to embrace the present (not even the
> future).
>
> Long story short, +1 for JDK 17 as minimum for Maven 4.
>
> Kind regards,
> Enno
>
> 
> From: Romain Manni-Bucau 
> Sent: Saturday, July 23, 2022 6:55 PM
> To: Maven Developers List 
> Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
>
> Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell  a
> écrit :
>
> > No, 2 JDKs are not required by default. Only if you use --release={<17}
> and
> > don't trust running tests on 17 are the same as running tests on 8.
> > Yes, there are changes (certificates, XML libs, rhino, etc).
> >
>
> As explained it means you dont write a single test or dont care of the test
> results so yes it needs 2 jdk.
>
>
>
> > So, for most projects that's probably not needed. For those who think it
> is
> > needed, I don't have a lot of pity. But it will be a requirement for
> quite
> > a few commercial projects, like Containers (JavaEE, as they will need to
> be
> > Java 8 as long as 2030ish due to extended support contracts).
> >
> > That said, I'm still thinking Java 17 will be a sane default.
> >
> >
> > On Sat, 23 Jul 2022, 10:50 Delany,  wrote:
> >
> > > Using mvnd with toolchains doesn't improve the situation, in fact
> > > toolchains seem to invalidate any benefit of using mvnd.
> > > Even if this was resolved, is it fair to require mvnd?
> > > Delany
> > >
> > >
> > > On Sat, 23 Jul 2022 at 10:17, Mark Derricutt  wrote:
> > >
> > > >  Is that due to cold starting the JVM each time?
> > > >
> > > > I wonder if mvnd supports toolchains effectively?  Or if that could
> be
> > an
> > > > avenue to try.
> > > > --
> > > > "Great artists are extremely selfish and arrogant things" — Steven
> > > Wilson,
> > > > Porcupine Tree
> > > >
> > > > On 23/07/2022 at 8:13:23 PM, Delany 
> > wrote:
> > > >
> > > > > I tried toolchains but dropped it because of the exorbitant
> > performance
> > > > > costs.
> > > > > A multi-module build that normally built in 3:50 took 10:34, and
> > that's
> > > > > with toolchaining only maven-compiler-plugin.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

[ANN] Apache Maven Parent POMs 37 Released

2022-07-23 Thread Slawomir Jaranowski 
The Apache Maven team is pleased to announce the release of the Maven
Parent POMs Version 37.

Maven Parent POMs include Maven Parent POM itself, but also Maven Plugins
Parent POM, Maven Shared Components Parent POM, Maven Skins Parent POM and
Maven Doxia Tools Parent POM.

https://maven.apache.org/pom/maven/

You should specify the version in your project as parent like the following:


 org.apache.maven
 maven-parent
 37


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/pom/maven/download.html


Release Notes - Maven POMs - Version MAVEN-37

** New Feature
* [MPOM-322] - Add link to ASF privacy policy

** Task
* [MPOM-317] - Remove custom Matomo code when Fluido Skin 1.11.0 is used
* [MPOM-324] - Drop Social Media Plug-ins from documentation

** Dependency upgrade
* [MPOM-328] - Bump maven-pmd-plugin from 3.16.0 to 3.17.0
* [MPOM-331] - Upgrade Surefire to 3.0.0-M7
* [MPOM-334] - Upgrade fluido skin to 1.11.1
* [MPOM-336] - Bump maven-toolchains-plugin from 3.0.0 to 3.1.0
* [MPOM-338] - Bump extra-enforcer-rules from 1.5.1 to 1.6.0
* [MPOM-339] - Upgrade Parent to 27

Enjoy,

-The Apache Maven team

Re: [VOTE] Release Maven Resources Plugin version 3.3.0

2022-07-23 Thread Michael Osipov 

Am 2022-07-23 um 20:08 schrieb Michael Osipov:

Hi,

We solved 11 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317827&version=12348676

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOURCES%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-1789/
https://repository.apache.org/content/repositories/maven-1789/org/apache/maven/plugins/maven-resources-plugin/3.3.0/maven-resources-plugin-3.3.0-source-release.zip

Source release checksum(s):
maven-resources-plugin-3.3.0-source-release.zip
sha512: 
c7df1d5713d08c942d2f6b3a1b3d8463e3b5ef284470bb0efc2bbb241c5f224747e43007c9af6bdef82d4e220d926dbf490a959b6c290bc9c0106db70fc74752


Staging site:
https://maven.apache.org/plugins-archives/maven-resources-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1


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

[RESULT] [VOTE] Release Apache Maven Parent POMs version 37

2022-07-23 Thread Slawomir Jaranowski 
Hi,

The vote has passed with the following result:

+1 : Michael Osipov, Tamás Cservenák, Karl Heinz Marbaise, Sylwester
Lachiewicz, Olivier Lamy, Guillaume Nodet,


PMC quorum: reached

I will promote the source release zip file to Apache distribution area and
the artifacts to the central repo.

-- 
Sławomir Jaranowski

Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Enno Thieleke 
Fwiw:

Romain, I think you're exaggerating. The answer is, like in most cases: "it 
depends".

Most people, we're most likely talking 95-99% here, will happily use JDK 17 
with Maven 4.

Some people might need to compile for lower sources and targets, but running 
tests for those builds in JDK 17 instead of, let's say 11, _will suffice in 
most cases_.

Yes, there will be edge cases where people will be forced to use different JDKs 
at least for tests, some even for builds. But that's possible, so they won't 
get left behind.

Regarding mvnd: It's not a silver bullet. It never was and it never will be. 
Whenever a build spawns new JVMs (for tests or other tasks), it doesn't benefit 
from mvnd anymore (in as much as it would without spawning new JVMs).

To not use the latest (LTS) JDK in order to "better" support the 1-5% of the 
Maven users, who're still using obsolete JVMs (I'm obviously referring to 
Karl's assumption, which I agree with), would be a kick in the teeth of all 
Maven developers, who finally want to embrace the present (not even the future).

Long story short, +1 for JDK 17 as minimum for Maven 4.

Kind regards,
Enno


From: Romain Manni-Bucau 
Sent: Saturday, July 23, 2022 6:55 PM
To: Maven Developers List 
Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0

Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell  a
écrit :

> No, 2 JDKs are not required by default. Only if you use --release={<17} and
> don't trust running tests on 17 are the same as running tests on 8.
> Yes, there are changes (certificates, XML libs, rhino, etc).
>

As explained it means you dont write a single test or dont care of the test
results so yes it needs 2 jdk.



> So, for most projects that's probably not needed. For those who think it is
> needed, I don't have a lot of pity. But it will be a requirement for quite
> a few commercial projects, like Containers (JavaEE, as they will need to be
> Java 8 as long as 2030ish due to extended support contracts).
>
> That said, I'm still thinking Java 17 will be a sane default.
>
>
> On Sat, 23 Jul 2022, 10:50 Delany,  wrote:
>
> > Using mvnd with toolchains doesn't improve the situation, in fact
> > toolchains seem to invalidate any benefit of using mvnd.
> > Even if this was resolved, is it fair to require mvnd?
> > Delany
> >
> >
> > On Sat, 23 Jul 2022 at 10:17, Mark Derricutt  wrote:
> >
> > >  Is that due to cold starting the JVM each time?
> > >
> > > I wonder if mvnd supports toolchains effectively?  Or if that could be
> an
> > > avenue to try.
> > > --
> > > "Great artists are extremely selfish and arrogant things" — Steven
> > Wilson,
> > > Porcupine Tree
> > >
> > > On 23/07/2022 at 8:13:23 PM, Delany 
> wrote:
> > >
> > > > I tried toolchains but dropped it because of the exorbitant
> performance
> > > > costs.
> > > > A multi-module build that normally built in 3:50 took 10:34, and
> that's
> > > > with toolchaining only maven-compiler-plugin.
> > > >
> > > >
> > > >
> > >
> >
>

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M3

2022-07-23 Thread Michael Osipov 

Am 2022-07-22 um 19:21 schrieb Michael Osipov:

Hi,

We solved 2 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12352119

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-1788/
https://repository.apache.org/content/repositories/maven-1788/org/apache/maven/plugins/maven-site-plugin/4.0.0-M3/maven-site-plugin-4.0.0-M3-source-release.zip

Source release checksum(s):
maven-site-plugin-4.0.0-M3-source-release.zip
sha512: 
76881569000e75679be355893a54d00f791f586637ff76f9767cb5034d184feb490b28994966d8f23deab870480868ee32e6525aa1aabd68108c047d1799d4c0


Staging site:
https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1


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

[VOTE] Release Maven Resources Plugin version 3.3.0

2022-07-23 Thread Michael Osipov 

Hi,

We solved 11 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317827&version=12348676

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOURCES%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-1789/
https://repository.apache.org/content/repositories/maven-1789/org/apache/maven/plugins/maven-resources-plugin/3.3.0/maven-resources-plugin-3.3.0-source-release.zip

Source release checksum(s):
maven-resources-plugin-3.3.0-source-release.zip
sha512: 
c7df1d5713d08c942d2f6b3a1b3d8463e3b5ef284470bb0efc2bbb241c5f224747e43007c9af6bdef82d4e220d926dbf490a959b6c290bc9c0106db70fc74752


Staging site:
https://maven.apache.org/plugins-archives/maven-resources-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Romain Manni-Bucau 
Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell  a
écrit :

> No, 2 JDKs are not required by default. Only if you use --release={<17} and
> don't trust running tests on 17 are the same as running tests on 8.
> Yes, there are changes (certificates, XML libs, rhino, etc).
>

As explained it means you dont write a single test or dont care of the test
results so yes it needs 2 jdk.



> So, for most projects that's probably not needed. For those who think it is
> needed, I don't have a lot of pity. But it will be a requirement for quite
> a few commercial projects, like Containers (JavaEE, as they will need to be
> Java 8 as long as 2030ish due to extended support contracts).
>
> That said, I'm still thinking Java 17 will be a sane default.
>
>
> On Sat, 23 Jul 2022, 10:50 Delany,  wrote:
>
> > Using mvnd with toolchains doesn't improve the situation, in fact
> > toolchains seem to invalidate any benefit of using mvnd.
> > Even if this was resolved, is it fair to require mvnd?
> > Delany
> >
> >
> > On Sat, 23 Jul 2022 at 10:17, Mark Derricutt  wrote:
> >
> > >  Is that due to cold starting the JVM each time?
> > >
> > > I wonder if mvnd supports toolchains effectively?  Or if that could be
> an
> > > avenue to try.
> > > --
> > > "Great artists are extremely selfish and arrogant things" — Steven
> > Wilson,
> > > Porcupine Tree
> > >
> > > On 23/07/2022 at 8:13:23 PM, Delany 
> wrote:
> > >
> > > > I tried toolchains but dropped it because of the exorbitant
> performance
> > > > costs.
> > > > A multi-module build that normally built in 3:50 took 10:34, and
> that's
> > > > with toolchaining only maven-compiler-plugin.
> > > >
> > > >
> > > >
> > >
> >
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Karl Heinz Marbaise 

Hi,

On 23.07.22 09:36, Romain Manni-Bucau wrote:

So to get started you must install maven, 2 jdk and configure it instead of
maven+jdk? Sounds like a usability killer for most projects IMHO - issue is
not the pom ;).


Can you imagine about how many of projects we are talking about?

My assumption is that not more than 1-5 % of all project really need
such setup... (maybe even less).

Kind regards
Karl Heinz Marbaise



Le sam. 23 juil. 2022 à 00:21, Benjamin Marwell  a
écrit :


KH just released a video on toolchains.
It's much easier than I remembered.

I'm changing my vote to 17. I don't see a reason to use 11 which will be
out of support soon. It's really just two properties used three times.


https://github.com/khmarbaise/youtube-videos/blob/main/episode-toolchains/pom.xml

https://youtu.be/-KbDcJcglPc

Thanks Karl Heinz for sorting this out.
We should really promote toolchains.

+1 for 17.

   - Ben

On Fri, 22 Jul 2022, 21:33 Arnaud Héritier,  wrote:


I would say java 11 for maven 4 and 17 for maven 5 with the hope that it
won’t be here in many years

Le jeu. 21 juil. 2022 à 18:53, Benjamin Marwell  a
écrit :


I was going to answer: go for 17.

But running the tests on the same language level is really a good

argument.

So much changed: HttpClient, TLS and cipher suites, DNS resolution
(starting with Java 18 it will be pluggable!) etc.

Yes, in theory it should not fail. But this is (sadly) a strong

argument

against using Java 11+.

If it's just for language features, we could also use kotlin, groovy or
just a library like javaslang (now vavr.io) to receive some amount of

what

you would like to see. Groovy is even an Apache project and kotlin has
excellent support. Both can mimic sealed classes, have advanced

features

like traits etc.

Not saying I'm a big fan of this myself, but it *might* be an option to
think about.

Of course we could scare devs away or attract them. Who knows.

So, I deeply regret it, but I'd say go for 8 and make an early Maven 5
release with Java 17, then make all the major changes (new pom etc) in
Maven 6 instead of Maven 5.


On Wed, 20 Jul 2022, 17:08 Jorge Solórzano,  wrote:


Yes, I agree with Romain (and also many others that have the same
concerns), expecting that the behavior of testing with one JDK that
targets a lower JDK will "just works" is naive.

There are differences at bytecode level, just compile a class with
JDK17 --release 11 and the same class with JDK11 --release 11 and

then

compare with diffoscope to see them, this is one of the reasons that
you need to use the same major JDK version to get Reproducible

Builds,

you can't expect a build to be reproducible even if you target to the
same release.

I don't expect the bytecode differences to be a real issue, yet
without proper testing (using the same runtime that you target) you
can't be sure.

The HttpClient is one example where you have things like this bug:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8245245, fixed
only in Java 16+, meaning that while it *works* on Java 17, it will
fail on Java 11.

We all agree that Toolchains is the way to go for this kind of thing,
but it's important to mention that Toolchains create some friction

for

end users and a more involved setup.

And please don't get me wrong, I'm all for using JDK 17, but user
experience is also important.

On Wed, Jul 20, 2022 at 4:23 PM Romain Manni-Bucau
 wrote:


Was more due to tests failling but there is no guarantee there is

no

difference in the bytecode on one side and the most important IMHO

is

the

fact the run behavior can be different so at the end of the day you

cant

assume that because your build with java17 -release 8 worked that

it

will

run on your prod.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <

https://github.com/rmannibucau> |

LinkedIn  | Book
<







https://www.packtpub.com/application-development/java-ee-8-high-performance




Le mer. 20 juil. 2022 à 16:16, Tomo Suzuki



a

écrit :


Hi Romain,


the while loop was not exactly the same


Did you observe the difference in the while loop bytecode cause

an

issue in

Java 8 users?

Regards,
Tomo



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





--


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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Karl Heinz Marbaise 

Hi,

On 23.07.22 10:13, Delany wrote:

I tried toolchains but dropped it because of the exorbitant performance
costs.
A multi-module build that normally built in 3:50 took 10:34, and that's
with toolchaining only maven-compiler-plugin.
Delany


Can you tell when you have tested that? How many modules do you have
have? What kind of project ?

Do you have an example of that? Have you configured to fork of compiler
plugin..please give much much more information so we need to analyze this?

Kind regards
Karl Heinz Marbaise





On Sat, 23 Jul 2022 at 00:21, Benjamin Marwell  wrote:


KH just released a video on toolchains.
It's much easier than I remembered.

I'm changing my vote to 17. I don't see a reason to use 11 which will be
out of support soon. It's really just two properties used three times.


https://github.com/khmarbaise/youtube-videos/blob/main/episode-toolchains/pom.xml

https://youtu.be/-KbDcJcglPc

Thanks Karl Heinz for sorting this out.
We should really promote toolchains.

+1 for 17.

   - Ben

On Fri, 22 Jul 2022, 21:33 Arnaud Héritier,  wrote:


I would say java 11 for maven 4 and 17 for maven 5 with the hope that it
won’t be here in many years

Le jeu. 21 juil. 2022 à 18:53, Benjamin Marwell  a
écrit :


I was going to answer: go for 17.

But running the tests on the same language level is really a good

argument.

So much changed: HttpClient, TLS and cipher suites, DNS resolution
(starting with Java 18 it will be pluggable!) etc.

Yes, in theory it should not fail. But this is (sadly) a strong

argument

against using Java 11+.

If it's just for language features, we could also use kotlin, groovy or
just a library like javaslang (now vavr.io) to receive some amount of

what

you would like to see. Groovy is even an Apache project and kotlin has
excellent support. Both can mimic sealed classes, have advanced

features

like traits etc.

Not saying I'm a big fan of this myself, but it *might* be an option to
think about.

Of course we could scare devs away or attract them. Who knows.

So, I deeply regret it, but I'd say go for 8 and make an early Maven 5
release with Java 17, then make all the major changes (new pom etc) in
Maven 6 instead of Maven 5.


On Wed, 20 Jul 2022, 17:08 Jorge Solórzano,  wrote:


Yes, I agree with Romain (and also many others that have the same
concerns), expecting that the behavior of testing with one JDK that
targets a lower JDK will "just works" is naive.

There are differences at bytecode level, just compile a class with
JDK17 --release 11 and the same class with JDK11 --release 11 and

then

compare with diffoscope to see them, this is one of the reasons that
you need to use the same major JDK version to get Reproducible

Builds,

you can't expect a build to be reproducible even if you target to the
same release.

I don't expect the bytecode differences to be a real issue, yet
without proper testing (using the same runtime that you target) you
can't be sure.

The HttpClient is one example where you have things like this bug:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8245245, fixed
only in Java 16+, meaning that while it *works* on Java 17, it will
fail on Java 11.

We all agree that Toolchains is the way to go for this kind of thing,
but it's important to mention that Toolchains create some friction

for

end users and a more involved setup.

And please don't get me wrong, I'm all for using JDK 17, but user
experience is also important.

On Wed, Jul 20, 2022 at 4:23 PM Romain Manni-Bucau
 wrote:


Was more due to tests failling but there is no guarantee there is

no

difference in the bytecode on one side and the most important IMHO

is

the

fact the run behavior can be different so at the end of the day you

cant

assume that because your build with java17 -release 8 worked that

it

will

run on your prod.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <

https://github.com/rmannibucau> |

LinkedIn  | Book
<







https://www.packtpub.com/application-development/java-ee-8-high-performance




Le mer. 20 juil. 2022 à 16:16, Tomo Suzuki



a

écrit :


Hi Romain,


the while loop was not exactly the same


Did you observe the difference in the while loop bytecode cause

an

issue in

Java 8 users?

Regards,
Tomo



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

Re: Suggestion for soft-breaking Maven Plugin 4.0 changes

2022-07-23 Thread Benjamin Marwell 
Let's not forget checksum validation by default. I think it's already
planned, but just wanted to mention it.




On Fri, 22 Jul 2022, 07:55 Olivier Lamy,  wrote:

> On Fri, 22 Jul 2022 at 05:59, Guillaume Nodet  wrote:
>
> > I would propose to add the -e flag by default and also the
> >
>
> +1
>
>
> > -DtrimStackTrace=false.
> >
>
> surefire has been changed in 3.0.0-M6 with this default value ;)
>
>
> >
> > Le jeu. 21 juil. 2022 à 20:24, Benjamin Marwell  a
> > écrit :
> >
> > > Hi everyone,
> > >
> > > as discussed in Slack, here are a few ideas for Maven 4.0 Plugin
> > > default's changes.
> > > Rationale: Convention over configuration, but things have diverged
> > > from when Maven 3 was started.
> > >
> > > * Set the default Java Source file encoding to UTF-8.
> > > This seems to receive a broad agreement. Not only is UTF-8 default on
> > > most platforms nowadays (UTF-16 on Windows), it also aligns with Java
> > > 18+, most user configurations and getting rid of the annoying warning
> > > "is platform dependent". Plus, it is 100% compatible with ASCII and
> > > mostly compatible with other encodings.
> > >
> > > * Setting the default javadoc-plugin verbosity to quiet via
> "quiet=true".
> > > [1]
> > > This was the default before Java 1.4.2 anyway, and it will only make
> > > the list of generated html sites disappear.
> > >
> > > * Setting failOnMissingWebXml to "false" by default. Romain suggested
> > > this was planned for the next major release, but I was not able to
> > > find an issue about this.
> > >
> > > There seems to have been some jira tickets about this, all set to
> > > resolved+fixed, but I cannot see the actual implementation which made
> > > it into the plugin. [2], [3]. Setting the default to "false" based on
> > > the existence of annotations or a dependency might still be a valid
> > > idea, but this got vastly more complicated, no question. So just
> > > setting it to "false" might do it, but it will break builds which do
> > > not use annotations. There are good reasons for this, e.g. using a
> > > particular startup order for listeners.
> > >
> > > That said, I am not sure about the last one unless we can identify
> > > *for sure* there are *some* kind servlets/listeners etc. present in
> > > the .war file. My -0.5 on this one unless someone can come up with a
> > > neat solution.
> > >
> > > So, what do you think? Are there more sane defaults we should set for
> > > Maven 4.0?
> > >
> > > - Ben
> > >
> > >
> > > [1]:
> > >
> >
> https://maven.apache.org/plugins/maven-javadoc-plugin/test-jar-mojo.html#quiet
> > > [2]: https://issues.apache.org/jira/browse/MWAR-396
> > > [3]: https://issues.apache.org/jira/browse/MWAR-262
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> > --
> > 
> > Guillaume Nodet
> >
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Benjamin Marwell 
No, 2 JDKs are not required by default. Only if you use --release={<17} and
don't trust running tests on 17 are the same as running tests on 8.
Yes, there are changes (certificates, XML libs, rhino, etc).

So, for most projects that's probably not needed. For those who think it is
needed, I don't have a lot of pity. But it will be a requirement for quite
a few commercial projects, like Containers (JavaEE, as they will need to be
Java 8 as long as 2030ish due to extended support contracts).

That said, I'm still thinking Java 17 will be a sane default.


On Sat, 23 Jul 2022, 10:50 Delany,  wrote:

> Using mvnd with toolchains doesn't improve the situation, in fact
> toolchains seem to invalidate any benefit of using mvnd.
> Even if this was resolved, is it fair to require mvnd?
> Delany
>
>
> On Sat, 23 Jul 2022 at 10:17, Mark Derricutt  wrote:
>
> >  Is that due to cold starting the JVM each time?
> >
> > I wonder if mvnd supports toolchains effectively?  Or if that could be an
> > avenue to try.
> > --
> > "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> > Porcupine Tree
> >
> > On 23/07/2022 at 8:13:23 PM, Delany  wrote:
> >
> > > I tried toolchains but dropped it because of the exorbitant performance
> > > costs.
> > > A multi-module build that normally built in 3:50 took 10:34, and that's
> > > with toolchaining only maven-compiler-plugin.
> > >
> > >
> > >
> >
>

[RESULT] [VOTE] Maven Install Plugin 3.0.1

2022-07-23 Thread Karl Heinz Marbaise 

Hi,

The vote has passed with the following result:

+1 : Karl Heinz Marbaise, Michael Osipov, Olivier Lamy, Václav Haisman,
Guillaume Nodet, Tamás Cservanák, slawomir Jaranowski, Arnaud Héritier,

PMC quorum: reached.


I will promote the source release zip file to Apache distribution area
and the artifacts to the central repo.

Kind regards
Karl Heinz Marbaise

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

[ANN] Maven Assembly Plugin 3.4.2 released

2022-07-23 Thread Michael Osipov 
The Apache Maven team is pleased to announce the release of the Maven 
Assembly Plugin version 3.4.2.


https://maven.apache.org/plugins/maven-assembly-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-assembly-plugin
  3.4.2



Release Notes - Maven Assembly Plugin - Version 3.4.2

** Bug
* [MASSEMBLY-969] - Excludes filtering in  3.4.0 and 3.4.1 differs 
from 3.3.0


** Task
* [MASSEMBLY-949] - Examples should refer to https instead of http


Enjoy,

-The Apache Maven team

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

[RESULT] [VOTE] Release Maven Assembly Plugin version 3.4.2

2022-07-23 Thread Michael Osipov 

Hi,

The vote has passed with the following result:

+1: Michael Osipov, Karl Heinz Marbaise, Sylwester Lachiewicz, Tamás 
Cservenák, Slawomir Jaranowski


PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Delany 
Using mvnd with toolchains doesn't improve the situation, in fact
toolchains seem to invalidate any benefit of using mvnd.
Even if this was resolved, is it fair to require mvnd?
Delany


On Sat, 23 Jul 2022 at 10:17, Mark Derricutt  wrote:

>  Is that due to cold starting the JVM each time?
>
> I wonder if mvnd supports toolchains effectively?  Or if that could be an
> avenue to try.
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
> On 23/07/2022 at 8:13:23 PM, Delany  wrote:
>
> > I tried toolchains but dropped it because of the exorbitant performance
> > costs.
> > A multi-module build that normally built in 3:50 took 10:34, and that's
> > with toolchaining only maven-compiler-plugin.
> >
> >
> >
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Christoph Läubrich 
That's why I suggested a way to configure/require/fetch/... a JDK in the 
pom then you need only install maven and a JVM.


For some products it is even that they ship a JVM, e.g. maven could 
create a stripped down JVM only contain what maven requires with Java 
11, then it would only be a matter of download maven and extract it to a 
folder, everything set, no stupid "JAVA HOME NOT FOUND" if there are 
spaces in the path or complex guessing


Projects would configure the desired compile/test/run JVM in the pom and 
no more issues with missing/wrong JVM ;-)




Am 23.07.22 um 09:36 schrieb Romain Manni-Bucau:

So to get started you must install maven, 2 jdk and configure it instead of
maven+jdk? Sounds like a usability killer for most projects IMHO - issue is
not the pom ;).

Le sam. 23 juil. 2022 à 00:21, Benjamin Marwell  a
écrit :


KH just released a video on toolchains.
It's much easier than I remembered.

I'm changing my vote to 17. I don't see a reason to use 11 which will be
out of support soon. It's really just two properties used three times.


https://github.com/khmarbaise/youtube-videos/blob/main/episode-toolchains/pom.xml

https://youtu.be/-KbDcJcglPc

Thanks Karl Heinz for sorting this out.
We should really promote toolchains.

+1 for 17.

   - Ben

On Fri, 22 Jul 2022, 21:33 Arnaud Héritier,  wrote:


I would say java 11 for maven 4 and 17 for maven 5 with the hope that it
won’t be here in many years

Le jeu. 21 juil. 2022 à 18:53, Benjamin Marwell  a
écrit :


I was going to answer: go for 17.

But running the tests on the same language level is really a good

argument.

So much changed: HttpClient, TLS and cipher suites, DNS resolution
(starting with Java 18 it will be pluggable!) etc.

Yes, in theory it should not fail. But this is (sadly) a strong

argument

against using Java 11+.

If it's just for language features, we could also use kotlin, groovy or
just a library like javaslang (now vavr.io) to receive some amount of

what

you would like to see. Groovy is even an Apache project and kotlin has
excellent support. Both can mimic sealed classes, have advanced

features

like traits etc.

Not saying I'm a big fan of this myself, but it *might* be an option to
think about.

Of course we could scare devs away or attract them. Who knows.

So, I deeply regret it, but I'd say go for 8 and make an early Maven 5
release with Java 17, then make all the major changes (new pom etc) in
Maven 6 instead of Maven 5.


On Wed, 20 Jul 2022, 17:08 Jorge Solórzano,  wrote:


Yes, I agree with Romain (and also many others that have the same
concerns), expecting that the behavior of testing with one JDK that
targets a lower JDK will "just works" is naive.

There are differences at bytecode level, just compile a class with
JDK17 --release 11 and the same class with JDK11 --release 11 and

then

compare with diffoscope to see them, this is one of the reasons that
you need to use the same major JDK version to get Reproducible

Builds,

you can't expect a build to be reproducible even if you target to the
same release.

I don't expect the bytecode differences to be a real issue, yet
without proper testing (using the same runtime that you target) you
can't be sure.

The HttpClient is one example where you have things like this bug:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8245245, fixed
only in Java 16+, meaning that while it *works* on Java 17, it will
fail on Java 11.

We all agree that Toolchains is the way to go for this kind of thing,
but it's important to mention that Toolchains create some friction

for

end users and a more involved setup.

And please don't get me wrong, I'm all for using JDK 17, but user
experience is also important.

On Wed, Jul 20, 2022 at 4:23 PM Romain Manni-Bucau
 wrote:


Was more due to tests failling but there is no guarantee there is

no

difference in the bytecode on one side and the most important IMHO

is

the

fact the run behavior can be different so at the end of the day you

cant

assume that because your build with java17 -release 8 worked that

it

will

run on your prod.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <

https://github.com/rmannibucau> |

LinkedIn  | Book
<







https://www.packtpub.com/application-development/java-ee-8-high-performance




Le mer. 20 juil. 2022 à 16:16, Tomo Suzuki



a

écrit :


Hi Romain,


the while loop was not exactly the same


Did you observe the difference in the while loop bytecode cause

an

issue in

Java 8 users?

Regards,
Tomo



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





--
Arnaud Héritier
Twitter/GitHub/... : aheritier







-
To

Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Mark Derricutt 
 Is that due to cold starting the JVM each time?

I wonder if mvnd supports toolchains effectively?  Or if that could be an
avenue to try.
-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On 23/07/2022 at 8:13:23 PM, Delany  wrote:

> I tried toolchains but dropped it because of the exorbitant performance
> costs.
> A multi-module build that normally built in 3:50 took 10:34, and that's
> with toolchaining only maven-compiler-plugin.
>
>
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Delany 
I tried toolchains but dropped it because of the exorbitant performance
costs.
A multi-module build that normally built in 3:50 took 10:34, and that's
with toolchaining only maven-compiler-plugin.
Delany


On Sat, 23 Jul 2022 at 00:21, Benjamin Marwell  wrote:

> KH just released a video on toolchains.
> It's much easier than I remembered.
>
> I'm changing my vote to 17. I don't see a reason to use 11 which will be
> out of support soon. It's really just two properties used three times.
>
>
> https://github.com/khmarbaise/youtube-videos/blob/main/episode-toolchains/pom.xml
>
> https://youtu.be/-KbDcJcglPc
>
> Thanks Karl Heinz for sorting this out.
> We should really promote toolchains.
>
> +1 for 17.
>
>   - Ben
>
> On Fri, 22 Jul 2022, 21:33 Arnaud Héritier,  wrote:
>
> > I would say java 11 for maven 4 and 17 for maven 5 with the hope that it
> > won’t be here in many years
> >
> > Le jeu. 21 juil. 2022 à 18:53, Benjamin Marwell  a
> > écrit :
> >
> > > I was going to answer: go for 17.
> > >
> > > But running the tests on the same language level is really a good
> > argument.
> > > So much changed: HttpClient, TLS and cipher suites, DNS resolution
> > > (starting with Java 18 it will be pluggable!) etc.
> > >
> > > Yes, in theory it should not fail. But this is (sadly) a strong
> argument
> > > against using Java 11+.
> > >
> > > If it's just for language features, we could also use kotlin, groovy or
> > > just a library like javaslang (now vavr.io) to receive some amount of
> > what
> > > you would like to see. Groovy is even an Apache project and kotlin has
> > > excellent support. Both can mimic sealed classes, have advanced
> features
> > > like traits etc.
> > >
> > > Not saying I'm a big fan of this myself, but it *might* be an option to
> > > think about.
> > >
> > > Of course we could scare devs away or attract them. Who knows.
> > >
> > > So, I deeply regret it, but I'd say go for 8 and make an early Maven 5
> > > release with Java 17, then make all the major changes (new pom etc) in
> > > Maven 6 instead of Maven 5.
> > >
> > >
> > > On Wed, 20 Jul 2022, 17:08 Jorge Solórzano,  wrote:
> > >
> > > > Yes, I agree with Romain (and also many others that have the same
> > > > concerns), expecting that the behavior of testing with one JDK that
> > > > targets a lower JDK will "just works" is naive.
> > > >
> > > > There are differences at bytecode level, just compile a class with
> > > > JDK17 --release 11 and the same class with JDK11 --release 11 and
> then
> > > > compare with diffoscope to see them, this is one of the reasons that
> > > > you need to use the same major JDK version to get Reproducible
> Builds,
> > > > you can't expect a build to be reproducible even if you target to the
> > > > same release.
> > > >
> > > > I don't expect the bytecode differences to be a real issue, yet
> > > > without proper testing (using the same runtime that you target) you
> > > > can't be sure.
> > > >
> > > > The HttpClient is one example where you have things like this bug:
> > > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8245245, fixed
> > > > only in Java 16+, meaning that while it *works* on Java 17, it will
> > > > fail on Java 11.
> > > >
> > > > We all agree that Toolchains is the way to go for this kind of thing,
> > > > but it's important to mention that Toolchains create some friction
> for
> > > > end users and a more involved setup.
> > > >
> > > > And please don't get me wrong, I'm all for using JDK 17, but user
> > > > experience is also important.
> > > >
> > > > On Wed, Jul 20, 2022 at 4:23 PM Romain Manni-Bucau
> > > >  wrote:
> > > > >
> > > > > Was more due to tests failling but there is no guarantee there is
> no
> > > > > difference in the bytecode on one side and the most important IMHO
> is
> > > the
> > > > > fact the run behavior can be different so at the end of the day you
> > > cant
> > > > > assume that because your build with java17 -release 8 worked that
> it
> > > will
> > > > > run on your prod.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> > > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > > >
> > > > >
> > > > > Le mer. 20 juil. 2022 à 16:16, Tomo Suzuki
> >  > > >
> > > > a
> > > > > écrit :
> > > > >
> > > > > > Hi Romain,
> > > > > >
> > > > > > > the while loop was not exactly the same
> > > > > >
> > > > > > Did you observe the difference in the while loop bytecode cause
> an
> > > > issue in
> > > > > > Java 8 users?
> > > > > >
> > > > > > Regards,
> > > > > > Tomo
> > > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubsc

Re: Question - JDK Minimum of future Apache Maven 4.0.0

2022-07-23 Thread Romain Manni-Bucau 
So to get started you must install maven, 2 jdk and configure it instead of
maven+jdk? Sounds like a usability killer for most projects IMHO - issue is
not the pom ;).

Le sam. 23 juil. 2022 à 00:21, Benjamin Marwell  a
écrit :

> KH just released a video on toolchains.
> It's much easier than I remembered.
>
> I'm changing my vote to 17. I don't see a reason to use 11 which will be
> out of support soon. It's really just two properties used three times.
>
>
> https://github.com/khmarbaise/youtube-videos/blob/main/episode-toolchains/pom.xml
>
> https://youtu.be/-KbDcJcglPc
>
> Thanks Karl Heinz for sorting this out.
> We should really promote toolchains.
>
> +1 for 17.
>
>   - Ben
>
> On Fri, 22 Jul 2022, 21:33 Arnaud Héritier,  wrote:
>
> > I would say java 11 for maven 4 and 17 for maven 5 with the hope that it
> > won’t be here in many years
> >
> > Le jeu. 21 juil. 2022 à 18:53, Benjamin Marwell  a
> > écrit :
> >
> > > I was going to answer: go for 17.
> > >
> > > But running the tests on the same language level is really a good
> > argument.
> > > So much changed: HttpClient, TLS and cipher suites, DNS resolution
> > > (starting with Java 18 it will be pluggable!) etc.
> > >
> > > Yes, in theory it should not fail. But this is (sadly) a strong
> argument
> > > against using Java 11+.
> > >
> > > If it's just for language features, we could also use kotlin, groovy or
> > > just a library like javaslang (now vavr.io) to receive some amount of
> > what
> > > you would like to see. Groovy is even an Apache project and kotlin has
> > > excellent support. Both can mimic sealed classes, have advanced
> features
> > > like traits etc.
> > >
> > > Not saying I'm a big fan of this myself, but it *might* be an option to
> > > think about.
> > >
> > > Of course we could scare devs away or attract them. Who knows.
> > >
> > > So, I deeply regret it, but I'd say go for 8 and make an early Maven 5
> > > release with Java 17, then make all the major changes (new pom etc) in
> > > Maven 6 instead of Maven 5.
> > >
> > >
> > > On Wed, 20 Jul 2022, 17:08 Jorge Solórzano,  wrote:
> > >
> > > > Yes, I agree with Romain (and also many others that have the same
> > > > concerns), expecting that the behavior of testing with one JDK that
> > > > targets a lower JDK will "just works" is naive.
> > > >
> > > > There are differences at bytecode level, just compile a class with
> > > > JDK17 --release 11 and the same class with JDK11 --release 11 and
> then
> > > > compare with diffoscope to see them, this is one of the reasons that
> > > > you need to use the same major JDK version to get Reproducible
> Builds,
> > > > you can't expect a build to be reproducible even if you target to the
> > > > same release.
> > > >
> > > > I don't expect the bytecode differences to be a real issue, yet
> > > > without proper testing (using the same runtime that you target) you
> > > > can't be sure.
> > > >
> > > > The HttpClient is one example where you have things like this bug:
> > > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8245245, fixed
> > > > only in Java 16+, meaning that while it *works* on Java 17, it will
> > > > fail on Java 11.
> > > >
> > > > We all agree that Toolchains is the way to go for this kind of thing,
> > > > but it's important to mention that Toolchains create some friction
> for
> > > > end users and a more involved setup.
> > > >
> > > > And please don't get me wrong, I'm all for using JDK 17, but user
> > > > experience is also important.
> > > >
> > > > On Wed, Jul 20, 2022 at 4:23 PM Romain Manni-Bucau
> > > >  wrote:
> > > > >
> > > > > Was more due to tests failling but there is no guarantee there is
> no
> > > > > difference in the bytecode on one side and the most important IMHO
> is
> > > the
> > > > > fact the run behavior can be different so at the end of the day you
> > > cant
> > > > > assume that because your build with java17 -release 8 worked that
> it
> > > will
> > > > > run on your prod.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> > > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > > >
> > > > >
> > > > > Le mer. 20 juil. 2022 à 16:16, Tomo Suzuki
> >  > > >
> > > > a
> > > > > écrit :
> > > > >
> > > > > > Hi Romain,
> > > > > >
> > > > > > > the while loop was not exactly the same
> > > > > >
> > > > > > Did you observe the difference in the while loop bytecode cause
> an
> > > > issue in
> > > > > > Java 8 users?
> > > > > >
> > > > > > Regards,
> > > > > > Tomo
> > > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For