Re: [VOTE] Release Apache Maven Release Plugin version 3.0.1

+1 On Wed, 31 May 2023 at 07:35, Slawomir Jaranowski wrote: > > Hi, > > We solved 8 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824=12353136 > > There are still a couple of issues left in JIRA: >

Re: Question - JDK Minimum of future Apache Maven 4.0.0

I'm not sure I would worry too much about that David.  I think most devs who want better syntax moved from Java sometime ago.  They might still be on the JVM just not writing Java.  Also, Maven is a mature project.  I don't think devs considering contributing to it are thinking about using the

Re: Question - JDK Minimum of future Apache Maven 4.0.0

Perso I do not have any issue using 17. By curiosity, I wonder what sort of 17 (or 9+) features we really want/need? Pattern matching for switch? record (so we can get rid of Modello but record will be not compatible with previous standard beans). On Fri, 2 Jun 2023 at 09:17, David Jencks

Re: Question - JDK Minimum of future Apache Maven 4.0.0

I wonder if having maven require java 8 syntax discourages any potential contributors who are used to coding using more recent developments. I have no idea how to tell, but maybe someone else does. David Jencks > On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise wrote: > > Hi, > > my clear

Re: Question - JDK Minimum of future Apache Maven 4.0.0

Hi, my clear opinion is to go with most recent JDK LTS version for the release point of Maven 4.0.0 which I assume will be JDK 21... That means clear the build time requirement which is completely different from runtime of an application. Older JDK's are supported by some vendors by having

Re: Question - JDK Minimum of future Apache Maven 4.0.0

As an FYI - https://adoptium.net/en-GB/support/ can give a guide as to the thinking around OSS support for Java 8 (Nov 2026 is the minimum timeline, it may extend). Cheers, Martijn On Thu, 1 Jun 2023 at 23:36, Elliotte Rusty Harold wrote: > On Thu, Jun 1, 2023 at 10:47 AM Romain Manni-Bucau >

Re: [DISCUSS] Maven runtime vs artifact runtime?

Howdy, define 3 Java versions in my toolchains.xml, and then add 3 executions for surefire like here? https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html Thanks T On Thu, Jun 1, 2023 at 6:39 PM Gary Gregory wrote: > I claim it is not wasteful to run unit tests on

Re: Maven 3.9.x plugins verifications

Howdy, did locally a change that any validation issues are always reported in DEBUG (left remains as before). Here is an example output: https://gist.github.com/cstamas/277a5c8b400af917e784a8b0f3f3db26 Simply put, DEBUG is always logged (for any kind), and if you use commands like in gist (or

Re: [DISCUSS] Maven runtime vs artifact runtime?

I claim it is not wasteful to run unit tests on Java 8, 11, and 17, which usually is the longest and most resource intensive part of a build. How would you do that were it not for a GitHub matrix? Gary On Thu, Jun 1, 2023, 08:01 Tamás Cservenák wrote: > Howdy, > > From recent discussions I

Re: Maven 3.9.x plugins verifications

+1, guess it should be off by default and on in verbose/-X. If user always want to see it or see only a subpart tunning is fine IMHO. Romain Manni-Bucau @rmannibucau | Blog | Old Blog |

Re: Maven 3.9.x plugins verifications

Howdy, well, am starting to think we should just use different loggers for these (by locality) and let users tweak logging as they wish? Or any other idea? Thanks T On Thu, Jun 1, 2023 at 2:44 PM Slawomir Jaranowski wrote: > We have some of discussion about this feature in 3.9.2 > > I saw

Re: [DISCUSS] Maven runtime vs artifact runtime?

On github I use the matrix across nearly everything just to show to users it works on various versions. It has nothing to do at all with what is used to release it. I use only jdk 17 on windows currently to release items on github. For my paying job. We don't have that level of resources

Maven 3.9.x plugins verifications

We have some of discussion about this feature in 3.9.2 I saw some negative opinions ... Maybe I am missing something I think that people's nature is that when they don't like something they will speak about it ... but when people like something don't speak about it. So I would like to say that I

Re: [DISCUSS] Maven runtime vs artifact runtime?

Howdy, But AFAIK the toolchain is similar, all you need is to setup maven-toolchains-plugin once and done, so is "central" as well, no? https://maven.apache.org/guides/mini/guide-using-toolchains.html What do you mean by "no need to configure here and there"? You mean toolchains.xml? Or POM

Re: [DISCUSS] Maven runtime vs artifact runtime?

Well, Guillaume's work kind of solves that...but still, even with gradle, toolchains are a nightmare for most users so it is quite common to end with the same jdk to build and run. Romain Manni-Bucau @rmannibucau | Blog | Old

Re: [DISCUSS] Maven runtime vs artifact runtime?

> Does Maven miss some features Just look at how gradle support toolchains: https://docs.gradle.org/current/userguide/toolchains.html That's all shows what maven refuses to support and leaving people think its easier to use the same JVM "from beginning to end": 1) First class declarative

Re: [DISCUSS] Maven runtime vs artifact runtime?

Hi Tamas, Think we have two kind of users: * toolchain ones (probably minority) -> most plugins are okish there * contextual ones (use the build jdk to run maven and build apps) So overall I think we are quite targetting that already. In terms of compat matrix, I agree it is werid to not build

[DISCUSS] Maven runtime vs artifact runtime?

Howdy, >From recent discussions I see an interesting pattern: it seems that people (even our PMCs) are using Maven in a way that is making sure that "same Java version" (I guess vendor + version) is used from "beginning" to "end". And "beginning" here means BUILDING (think workstations and CI

Re: Question - JDK Minimum of future Apache Maven 4.0.0

On Thu, Jun 1, 2023 at 10:47 AM Romain Manni-Bucau wrote: > Yep but this is also something an OSS product don't want to rely on (ie > particular vendor specificities which can change), so we should probably > stick to the global dates and align on these ones consistently. > Yes, but that

Re: Question - JDK Minimum of future Apache Maven 4.0.0

On Thu, Jun 1, 2023 at 12:51 PM Michael Osipov wrote: > Neither nor. Many use OpenJDK in production even w/o any commercial plans > because they are happy with that. So there is also C. > And that is fine, if they are happy with it, they should be happy with other "same age" tech, so they

Re: Question - JDK Minimum of future Apache Maven 4.0.0

Neither nor. Many use OpenJDK in production even w/o any commercial plans because they are happy with that. So there is also C. On 2023/06/01 10:48:28 Tamás Cservenák wrote: > This is silly. > So we need to support Java 8 in the future (not yet happened) Maven 4 > releases due: > > A) hobbyist

Re: Question - JDK Minimum of future Apache Maven 4.0.0

This is silly. So we need to support Java 8 in the future (not yet happened) Maven 4 releases due: A) hobbyist (personal/individual users or for non-production, development/testing purposes) OR B) commercial entities paying for licenses (commercial/business use of those public releases in

Re: Question - JDK Minimum of future Apache Maven 4.0.0

Le jeu. 1 juin 2023 à 12:39, Elliotte Rusty Harold a écrit : > On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet wrote: > > > > JDK 8 active support ended 15 months ago, so I think that's definitely > fine > > to require a newer version. > > This is a common misconception. JDK 8 is fully supported

Re: Question - JDK Minimum of future Apache Maven 4.0.0

On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet wrote: > > JDK 8 active support ended 15 months ago, so I think that's definitely fine > to require a newer version. This is a common misconception. JDK 8 is fully supported by multiple companies including Azul. It also seems supported by Oracle:

Re: Question - JDK Minimum of future Apache Maven 4.0.0

On 2023/06/01 06:28:18 Guillaume Nodet wrote: > JDK 8 active support ended 15 months ago, so I think that's definitely fine > to require a newer version. I don't think we should wait and support JDK 8 > until 2030 and then switch from JDK 8 to what, JDK 24 ? That's really not a > good plan imho

Re: Build cache extension release

I've resolved conflicts and merged https://github.com/apache/maven-build-cache-extension/pull/34 Le jeu. 1 juin 2023 à 07:27, Olivier Lamy a écrit : > Hi, > I'd like to release the build cache extension in the coming days. > If someone has something to merge or fix please let me know/ > >

Re: Question - JDK Minimum of future Apache Maven 4.0.0

Sounds like a plan to me we have to adopt the new JDK release schedule somehow anyway, we cant stick on java 8 now it is EOL and java 11 soon so today only java 17 is a fair option for users. Romain Manni-Bucau @rmannibucau | Blog

Re: Question - JDK Minimum of future Apache Maven 4.0.0

JDK 8 active support ended 15 months ago, so I think that's definitely fine to require a newer version. I don't think we should wait and support JDK 8 until 2030 and then switch from JDK 8 to what, JDK 24 ? That's really not a good plan imho and that's what maintenance branches are used for. The