Re: Question - JDK Minimum of future Apache Maven 4.0.0
Folks who think like that have been using Scala or Kotlin for at least 5 years by now. If you are still writing Java, it isn't for new features. Hunter PS If you want to use "new features" use Scala or Kotlin. If you want stability, use Java8. Using Java17 is a middle ground that gets nobody anything they way. That's why are having a hard time naming a new feature you want/need. On Saturday, June 3, 2023 at 06:16:11 AM PDT, Delany wrote: There may not be a killer feature, but the cumulative changes are appreciated, especially when you're used to them. Having closed the door on whatever came before List.of its like a miniature thorn in my side every time its not available. What motivated the change to JDK8? Were there any negative repercussions from that? All I'm reading is guesses about the impact. Is there an actual example of when the required JDK was raised and a tool was dropped or lost out to another because of it? Anyway, if there's nothing substantial to gain from the change from 8 to 17, then I don't see what is so disruptive about requiring it. Given that there's no single killer feature, and no obviously drawback, the argument should probably center on principles and even on determining a rule for Maven to follow (this isn't the first time this chestnut of an argument has come up). The vendor(s) and the source of the language are two different entities, so who is Maven beholden to? Since vendor interests are monetized in a way that Maven is not its more reasonable to expect Maven to follow Java's lead (rather than a vendor's support lifecycle). Despite the core principle of backward compatibility in the Java ecosystem, not adopting the latest LTS for a major Maven release is clearly going against Java's efforts to promote more regular update cycles and all the many automation and security benefits that comes with that. When people/businesses push back against updates I immediately think they must have some sub-standard DevOps workflow. Given that DevOps/JS cynics will probably gravitate to Java ecosystem this is unsurprising. Java is full of conservative sentiment. On the other hand there's the integrity of the language. Other languages make a hard fork, while Java risks being multiple languages - fun for those with decades of experience, but not encouraging to new faces who must choose between 5 different ways to solve a problem. One of my colleagues regularly portrays tech envy in sexual terms. Well guess what, we're human not robots and yes its "sexier" and more "satisfying" to work with JDK17. Ignoring that fact is itself irrational. Delany On Sat, 3 Jun 2023 at 11:46, Hervé Boutemy wrote: > +1 > > I really don't what benefit we get from going to Java 17 > > I perfectly see the impact we'll have on our users: for what benefit? > > notice that this will also impact all plugins: and given the few work done > on > plugins to clearly show what plugin version remains compatible with a JDK > release, I feel we're not taking the topic the right way > > Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit : > > 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 latest and greatest version of Java. Compatibility is probably a > > bigger concern for the user base. Just my opinion. > > > > Hunter > > On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks > > wrote: > > > > 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 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 particular special > > > support which most of the time requires special contracts (means also > > > paying money for it)..some of them offering builds without paying money > > > yes.. > > > > > > Older runtime target are supported with different approaches like > > > Toolchain or via `--release XX` which exists since JDK9+. > > > > > > > > > Furthermore if someone is not capable of upgrading the build > environment > > > to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X... > > > > > > If it would be requirement to port things back to 3.8.X or 3.9.X it > > > could be handled by someone who has the time etc. to do that ... if > not, > > > those people might think of paying
[VOTE] Release Maven Surefire version 3.1.2
Hi, we solved 15 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12353294 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved Staging repo: https://repository.apache.org/content/repositories/maven-1952/ https://repository.apache.org/content/repositories/maven-1952/org/apache/maven/surefire/surefire/3.1.2/surefire-3.1.2-source-release.zip Source release checksum(s): surefire-3.1.2-source-release.zip sha512: 18be516e0d43673fa9c6754f34a90138d9fac58b81267b81cf9ce0401389c63570dec5b4eea350c939ea9ed599ccc14a7be60fd7517b897ce983c2ac3ca6207d Staging site: https://maven.apache.org/surefire-archives/surefire-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: [VOTE] Release Maven Project Info Reports Plugin version 3.4.5
+1 sob., 3 cze 2023, 15:10 użytkownik Michael Osipov napisał: > Hi, > > we solved 4 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12353297 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MPIR/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1951/ > > https://repository.apache.org/content/repositories/maven-1951/org/apache/maven/plugins/maven-project-info-reports-plugin/3.4.5/maven-project-info-reports-plugin-3.4.5-source-release.zip > > Source release checksum(s): > maven-project-info-reports-plugin-3.4.5-source-release.zip > sha512: > > 75631dc43b83190bceab61f7311d620824bf1d8c8efd406014c287021fa4aeedb6fc40fd111f8ecc7c742bc1ae55ba039fec65bb3bba3cf6a8f514cb9bbc44e6 > > Staging site: > > https://maven.apache.org/plugins-archives/maven-project-info-reports-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
There may not be a killer feature, but the cumulative changes are appreciated, especially when you're used to them. Having closed the door on whatever came before List.of its like a miniature thorn in my side every time its not available. What motivated the change to JDK8? Were there any negative repercussions from that? All I'm reading is guesses about the impact. Is there an actual example of when the required JDK was raised and a tool was dropped or lost out to another because of it? Anyway, if there's nothing substantial to gain from the change from 8 to 17, then I don't see what is so disruptive about requiring it. Given that there's no single killer feature, and no obviously drawback, the argument should probably center on principles and even on determining a rule for Maven to follow (this isn't the first time this chestnut of an argument has come up). The vendor(s) and the source of the language are two different entities, so who is Maven beholden to? Since vendor interests are monetized in a way that Maven is not its more reasonable to expect Maven to follow Java's lead (rather than a vendor's support lifecycle). Despite the core principle of backward compatibility in the Java ecosystem, not adopting the latest LTS for a major Maven release is clearly going against Java's efforts to promote more regular update cycles and all the many automation and security benefits that comes with that. When people/businesses push back against updates I immediately think they must have some sub-standard DevOps workflow. Given that DevOps/JS cynics will probably gravitate to Java ecosystem this is unsurprising. Java is full of conservative sentiment. On the other hand there's the integrity of the language. Other languages make a hard fork, while Java risks being multiple languages - fun for those with decades of experience, but not encouraging to new faces who must choose between 5 different ways to solve a problem. One of my colleagues regularly portrays tech envy in sexual terms. Well guess what, we're human not robots and yes its "sexier" and more "satisfying" to work with JDK17. Ignoring that fact is itself irrational. Delany On Sat, 3 Jun 2023 at 11:46, Hervé Boutemy wrote: > +1 > > I really don't what benefit we get from going to Java 17 > > I perfectly see the impact we'll have on our users: for what benefit? > > notice that this will also impact all plugins: and given the few work done > on > plugins to clearly show what plugin version remains compatible with a JDK > release, I feel we're not taking the topic the right way > > Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit : > > 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 latest and greatest version of Java. Compatibility is probably a > > bigger concern for the user base. Just my opinion. > > > > Hunter > > On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks > > wrote: > > > > 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 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 particular special > > > support which most of the time requires special contracts (means also > > > paying money for it)..some of them offering builds without paying money > > > yes.. > > > > > > Older runtime target are supported with different approaches like > > > Toolchain or via `--release XX` which exists since JDK9+. > > > > > > > > > Furthermore if someone is not capable of upgrading the build > environment > > > to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X... > > > > > > If it would be requirement to port things back to 3.8.X or 3.9.X it > > > could be handled by someone who has the time etc. to do that ... if > not, > > > those people might think of paying someone to do that work... > > > > > > > > > The given argument about JPMS for migration causes issues is from my > > > point of view false-positive because migration to newer JDK versions > > > does not require JPMS usage... > > > > > > Even platforms like AWS support JDK17 in the meantime which is the > > > runtime... > > > > > > > > > Based on the argument we don't need features of JDK17+ I see a number > > > of things which could make our
[VOTE] Release Maven Project Info Reports Plugin version 3.4.5
Hi, we solved 4 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12353297 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/projects/MPIR/issues Staging repo: https://repository.apache.org/content/repositories/maven-1951/ https://repository.apache.org/content/repositories/maven-1951/org/apache/maven/plugins/maven-project-info-reports-plugin/3.4.5/maven-project-info-reports-plugin-3.4.5-source-release.zip Source release checksum(s): maven-project-info-reports-plugin-3.4.5-source-release.zip sha512: 75631dc43b83190bceab61f7311d620824bf1d8c8efd406014c287021fa4aeedb6fc40fd111f8ecc7c742bc1ae55ba039fec65bb3bba3cf6a8f514cb9bbc44e6 Staging site: https://maven.apache.org/plugins-archives/maven-project-info-reports-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
Le sam. 3 juin 2023 à 11:46, Hervé Boutemy a écrit : > +1 > > I really don't what benefit we get from going to Java 17 > > I perfectly see the impact we'll have on our users: for what benefit? > > notice that this will also impact all plugins: and given the few work done > on > plugins to clearly show what plugin version remains compatible with a JDK > release, I feel we're not taking the topic the right way > Can you detail it please? While we keep plugin-api java 8 compat - which is not under discussion there - there is no more impact than today normally. > > Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit : > > 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 latest and greatest version of Java. Compatibility is probably a > > bigger concern for the user base. Just my opinion. > > > > Hunter > > On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks > > wrote: > > > > 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 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 particular special > > > support which most of the time requires special contracts (means also > > > paying money for it)..some of them offering builds without paying money > > > yes.. > > > > > > Older runtime target are supported with different approaches like > > > Toolchain or via `--release XX` which exists since JDK9+. > > > > > > > > > Furthermore if someone is not capable of upgrading the build > environment > > > to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X... > > > > > > If it would be requirement to port things back to 3.8.X or 3.9.X it > > > could be handled by someone who has the time etc. to do that ... if > not, > > > those people might think of paying someone to do that work... > > > > > > > > > The given argument about JPMS for migration causes issues is from my > > > point of view false-positive because migration to newer JDK versions > > > does not require JPMS usage... > > > > > > Even platforms like AWS support JDK17 in the meantime which is the > > > runtime... > > > > > > > > > Based on the argument we don't need features of JDK17+ I see a number > > > of things which could make our handling/maintenance easier for example > > > using sealed classes to prevent exposing internal things to public > which > > > could be used etc. also some other small features (`var` for example; > > > Text-Blocks in Tests etc) or using records in some situation... > > > > > > > > > Based on the maintenance part it would mean in consequence to downgrade > > > to even JDK7... (or even lower) because you can get support for older > > > JDK version in some ways... (JDK7 from azul for example) > > > > > > Kind regards > > > Karl Heinz Marbaise > > > > > > [1] > https://www.oracle.com/java/technologies/java-se-support-roadmap.html > > > > > > - > > > 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 > > > > > > - > 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
+1 I really don't what benefit we get from going to Java 17 I perfectly see the impact we'll have on our users: for what benefit? notice that this will also impact all plugins: and given the few work done on plugins to clearly show what plugin version remains compatible with a JDK release, I feel we're not taking the topic the right way Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit : > 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 latest and greatest version of Java. Compatibility is probably a > bigger concern for the user base. Just my opinion. > > Hunter > On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks > wrote: > > 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 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 particular special > > support which most of the time requires special contracts (means also > > paying money for it)..some of them offering builds without paying money > > yes.. > > > > Older runtime target are supported with different approaches like > > Toolchain or via `--release XX` which exists since JDK9+. > > > > > > Furthermore if someone is not capable of upgrading the build environment > > to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X... > > > > If it would be requirement to port things back to 3.8.X or 3.9.X it > > could be handled by someone who has the time etc. to do that ... if not, > > those people might think of paying someone to do that work... > > > > > > The given argument about JPMS for migration causes issues is from my > > point of view false-positive because migration to newer JDK versions > > does not require JPMS usage... > > > > Even platforms like AWS support JDK17 in the meantime which is the > > runtime... > > > > > > Based on the argument we don't need features of JDK17+ I see a number > > of things which could make our handling/maintenance easier for example > > using sealed classes to prevent exposing internal things to public which > > could be used etc. also some other small features (`var` for example; > > Text-Blocks in Tests etc) or using records in some situation... > > > > > > Based on the maintenance part it would mean in consequence to downgrade > > to even JDK7... (or even lower) because you can get support for older > > JDK version in some ways... (JDK7 from azul for example) > > > > Kind regards > > Karl Heinz Marbaise > > > > [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html > > > > - > > 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
ANN] Apache Maven Release Plugin 3.0.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Release Plugin, version 3.0.1 https://maven.apache.org/maven-release/maven-release-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-release-plugin 3.0.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/maven-release/download.html Release Notes - Maven Release Plugin - Version 3.0.1 ** Bug * [MRELEASE-851] - javaHome parameter is ignored and inherited unexpectedly * [MRELEASE-1103] - Decryption of server password in settings.xml failed (works with 2.5.3) * [MRELEASE-1114] - Broken interaction of maven-gpg-plugin with Gpg4win Kleopatra since 3.0.0-M6 * [MRELEASE-1123] - Maven Release plugin doesn't work in maven 4 ** Improvement * [MRELEASE-1120] - Upgrade surefire version to 3.0.0 * [MRELEASE-1122] - add plugin's system requirements history ** Task * [MRELEASE-1127] - Refresh download page ** Dependency upgrade * [MRELEASE-1121] - Bump maven-shared-utils from 3.3.4 to 3.4.2 Enjoy, -The Apache Maven team
[RSEULT] [VOTE] Release Apache Maven Release Plugin version 3.0.1
Hi, The vote has passed with the following result: +1: Herve Boutemy, Sylwester Lachiewicz, Maarten Mulders, Tamás Cservenák, Guillaume Nodet, Olivier Lamy, Karl Heinz Marbaise 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
