Re: [VOTE] Release Maven Clean Plugin version 3.3.1
Le jeu. 15 juin 2023 à 03:24, Elliotte Rusty Harold a écrit : > This might not be blocking but there are some dependency issues: > > [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ > maven-clean-plugin --- > [WARNING] Used undeclared dependencies found: > [WARNING]commons-io:commons-io:jar:2.2:test > [WARNING]org.eclipse.aether:aether-api:jar:1.0.0.v20140518:provided > [WARNING] Unused declared dependencies found: > [WARNING]org.codehaus.plexus:plexus-xml:jar:4.0.0:provided > [WARNING]org.apache.maven:maven-compat:jar:3.2.5:test > [WARNING]junit:junit:jar:4.13.2:test > > The plexus-xml one is particularly interesting. Removing it from the > pom.xml breaks the build like this: > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time > elapsed: 0.04 s <<< FAILURE! - in > org.apache.maven.plugins.clean.CleanMojoTest > [ERROR] org.apache.maven.plugins.clean.CleanMojoTest.initializationError > Time elapsed: 0.013 s <<< ERROR! > java.lang.NoClassDefFoundError: > org/codehaus/plexus/util/xml/XmlStreamReader > > This seems to come from the superclass AbstractMojoTestCase. This > might be an error in the dependency declarations for > maven-pluign-testing. Or it might be an issue because > AbstractMojoTestCase expects to find XmlStreamReader in plexus-utils, > but it's no longer present in plexus-utils 4.0.0. Instead it comes > from plexus-xml. The more I look at it, the more likely this seems. > > So there are two issues here: > > 1. maven-dependency-analyzer is reporting a new false negative. In > general, analysis of dependencies gets much trickier when classes > belong to different artifacts in different versions. > 2. The presence of plexus-utils 4.0.0 means that maven-plugin-testing > no longer correctly declares its dependencies. > Good point. I wanted to clean the m-clean-p tests a bit before the release, but the newest 4.0.0-alpha-1 plugin-testing does not support maven 3.x. So I took at stab at it and raised https://github.com/apache/maven-clean-plugin/pull/27 and https://github.com/apache/maven-plugin-testing/pull/31 which upgrades to JUnit 5 and fix the dependencies. That could be included for the next release ! > > On Wed, Jun 14, 2023 at 6:58 PM Guillaume Nodet wrote: > > > > Hi, > > > > Fwiw, I've burned the 3.3.0 release, hence 3.3.1... > > > > we solved 5 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12351541 > > > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/projects/MCLEAN/issues > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1961/ > > > https://repository.apache.org/content/repositories/maven-1961/org/apache/maven/plugins/maven-clean-plugin/3.3.1/maven-clean-plugin-3.3.1-source-release.zip > > > > Source release checksum(s): > > maven-clean-plugin-3.3.1-source-release.zip > > sha512: > > > a195d19de931800d243aed24fa4eb86ac0961ed0a487ff88e513bccb183176b4dd401f870ad970f630ed72a86b5826b8b0e0bd50afecbae5ba7fb2d65a0eb9af > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > -- > > > > Guillaume Nodet > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Guillaume Nodet
Re: [VOTE] Release Maven Shade Plugin 3.5.0
+1 czw., 15 cze 2023, 04:39 użytkownik Olivier Lamy napisał: > +1 > > On Wed, 14 Jun 2023 at 04:54, Tamás Cservenák wrote: > > > > Howdy, > > > > We solved 8 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12352951 > > > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/projects/MSHADE/issues > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1958/ > > > > Source release SHA512 checksum(s): > > > 723fff11da6e39d1ffd1e1b6e6260a955169358ecd561fea70caecd79446455cdc829fb02982819f48f8eb8b1d2d7d0e5ebbda38d8fc3c76aa5c9087719fdc32 > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 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 Shade Plugin 3.5.0
+1 On Wed, 14 Jun 2023 at 04:54, Tamás Cservenák wrote: > > Howdy, > > We solved 8 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12352951 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MSHADE/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1958/ > > Source release SHA512 checksum(s): > 723fff11da6e39d1ffd1e1b6e6260a955169358ecd561fea70caecd79446455cdc829fb02982819f48f8eb8b1d2d7d0e5ebbda38d8fc3c76aa5c9087719fdc32 > > Staging site: > https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 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 Clean Plugin version 3.3.1
This might not be blocking but there are some dependency issues: [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-clean-plugin --- [WARNING] Used undeclared dependencies found: [WARNING]commons-io:commons-io:jar:2.2:test [WARNING]org.eclipse.aether:aether-api:jar:1.0.0.v20140518:provided [WARNING] Unused declared dependencies found: [WARNING]org.codehaus.plexus:plexus-xml:jar:4.0.0:provided [WARNING]org.apache.maven:maven-compat:jar:3.2.5:test [WARNING]junit:junit:jar:4.13.2:test The plexus-xml one is particularly interesting. Removing it from the pom.xml breaks the build like this: [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.04 s <<< FAILURE! - in org.apache.maven.plugins.clean.CleanMojoTest [ERROR] org.apache.maven.plugins.clean.CleanMojoTest.initializationError Time elapsed: 0.013 s <<< ERROR! java.lang.NoClassDefFoundError: org/codehaus/plexus/util/xml/XmlStreamReader This seems to come from the superclass AbstractMojoTestCase. This might be an error in the dependency declarations for maven-pluign-testing. Or it might be an issue because AbstractMojoTestCase expects to find XmlStreamReader in plexus-utils, but it's no longer present in plexus-utils 4.0.0. Instead it comes from plexus-xml. The more I look at it, the more likely this seems. So there are two issues here: 1. maven-dependency-analyzer is reporting a new false negative. In general, analysis of dependencies gets much trickier when classes belong to different artifacts in different versions. 2. The presence of plexus-utils 4.0.0 means that maven-plugin-testing no longer correctly declares its dependencies. On Wed, Jun 14, 2023 at 6:58 PM Guillaume Nodet wrote: > > Hi, > > Fwiw, I've burned the 3.3.0 release, hence 3.3.1... > > we solved 5 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12351541 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MCLEAN/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1961/ > https://repository.apache.org/content/repositories/maven-1961/org/apache/maven/plugins/maven-clean-plugin/3.3.1/maven-clean-plugin-3.3.1-source-release.zip > > Source release checksum(s): > maven-clean-plugin-3.3.1-source-release.zip > sha512: > a195d19de931800d243aed24fa4eb86ac0961ed0a487ff88e513bccb183176b4dd401f870ad970f630ed72a86b5826b8b0e0bd50afecbae5ba7fb2d65a0eb9af > > Staging site: > https://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > -- > > Guillaume Nodet -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Software Foundation Parent POM Version 30 Released
The Apache Maven team is pleased to announce the release of the Apache Software Foundation Parent POM Version, version 30 https://maven.apache.org/pom/asf/ You should specify the version in your project as parent like the following: org.apache apache 30 You can download the appropriate sources etc. from the download page: http://maven.apache.org/pom/asf/download.html Release Notes - Maven POMs - Version ASF-30 ** Bug * [MPOM-386] - update documentation for previous changes ** Improvement * [MPOM-289] - Use properties to define the versions of plugins ** Dependency upgrade * [MPOM-332] - Upgrade maven-deploy-plugin to 3.1.1 * [MPOM-344] - Update maven-remote-resources-plugin to 3.1.0 * [MPOM-388] - Upgrade Maven Dependency Plugin from 3.4.0 to 3.6.0 * [MPOM-389] - Upgrade to Maven Project Info Reports Plugin 3.4.2 * [MPOM-390] - Upgrade to Maven Fluido Skin 1.11.2 * [MPOM-394] - Upgrade Maven Project Info Reports Plugin to 3.4.5 * [MPOM-395] - upgrade Maven Compiler Plugin to 3.11.0 * [MPOM-396] - upgrade Maven Assembly Plugin to 3.6.0 * [MPOM-398] - Bump maven-help-plugin from 3.3.0 to 3.4.0 * [MPOM-400] - Bump maven-invoker-plugin from 3.3.0 to 3.5.1 * [MPOM-402] - Bump maven-javadoc-plugin from 3.4.1 to 3.5.0 * [MPOM-403] - Bump maven-enforcer-plugin from 3.1.0 to 3.3.0 * [MPOM-404] - Bump maven-scm-plugin from 1.13.0 to 2.0.1 * [MPOM-405] - Bump maven.plugin.tools.version from 3.7.0 to 3.9.0 * [MPOM-406] - Bump surefire/failsafe version from 2.22.2 to 3.1.2 * [MPOM-407] - Bump maven-release-plugin from 3.0.0-M7 to 3.0.1 * [MPOM-408] - Bump maven-scm-publish-plugin from 3.1.0 to 3.2.1 * [MPOM-409] - Bump apache-source-release-assembly-descriptor from 1.0.6 to 1.5 * [MPOM-410] - Bump maven-resources-plugin from 3.3.0 to 3.3.1 * [MPOM-411] - Bump maven-install-plugin from 3.1.0 to 3.1.1 * [MPOM-416] - Bump maven-gpg-plugin from 3.0.1 to 3.1.0 * [MPOM-417] - Bump maven-source-plugin from 3.2.1 to 3.3.0 * [MPOM-423] - Bump apache-jar-resource-bundle from 1.4 to 1.5 Enjoy, -The Apache Maven team
[RESULT] [VOTE] Release Apache ASF parent 30
Hi, The vote has passed with the following result: +1: Michael Osipov, Tamás Cservenák, Sylwester Lachiewicz, Guillaume Nodet, Hervé Boutemy 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: [VOTE] Release Maven Clean Plugin version 3.3.1
+1 Le mer. 14 juin 2023 à 21:33, Sylwester Lachiewicz a écrit : > +1 > > śr., 14 cze 2023 o 20:58 Guillaume Nodet napisał(a): > > > Hi, > > > > Fwiw, I've burned the 3.3.0 release, hence 3.3.1... > > > > we solved 5 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12351541 > > > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/projects/MCLEAN/issues > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1961/ > > > > > https://repository.apache.org/content/repositories/maven-1961/org/apache/maven/plugins/maven-clean-plugin/3.3.1/maven-clean-plugin-3.3.1-source-release.zip > > > > Source release checksum(s): > > maven-clean-plugin-3.3.1-source-release.zip > > sha512: > > > > > a195d19de931800d243aed24fa4eb86ac0961ed0a487ff88e513bccb183176b4dd401f870ad970f630ed72a86b5826b8b0e0bd50afecbae5ba7fb2d65a0eb9af > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > -- > > > > Guillaume Nodet > > >
Re: [VOTE] Release Maven Clean Plugin version 3.3.1
+1 śr., 14 cze 2023 o 20:58 Guillaume Nodet napisał(a): > Hi, > > Fwiw, I've burned the 3.3.0 release, hence 3.3.1... > > we solved 5 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12351541 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MCLEAN/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1961/ > > https://repository.apache.org/content/repositories/maven-1961/org/apache/maven/plugins/maven-clean-plugin/3.3.1/maven-clean-plugin-3.3.1-source-release.zip > > Source release checksum(s): > maven-clean-plugin-3.3.1-source-release.zip > sha512: > > a195d19de931800d243aed24fa4eb86ac0961ed0a487ff88e513bccb183176b4dd401f870ad970f630ed72a86b5826b8b0e0bd50afecbae5ba7fb2d65a0eb9af > > Staging site: > https://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > -- > > Guillaume Nodet >
[VOTE] Release Maven Clean Plugin version 3.3.1
Hi, Fwiw, I've burned the 3.3.0 release, hence 3.3.1... we solved 5 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12351541 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/projects/MCLEAN/issues Staging repo: https://repository.apache.org/content/repositories/maven-1961/ https://repository.apache.org/content/repositories/maven-1961/org/apache/maven/plugins/maven-clean-plugin/3.3.1/maven-clean-plugin-3.3.1-source-release.zip Source release checksum(s): maven-clean-plugin-3.3.1-source-release.zip sha512: a195d19de931800d243aed24fa4eb86ac0961ed0a487ff88e513bccb183176b4dd401f870ad970f630ed72a86b5826b8b0e0bd50afecbae5ba7fb2d65a0eb9af Staging site: https://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html -- Guillaume Nodet
Re: [VOTE] Release Maven WAR Plugin version 3.4.0
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 11.06.23 22:14, Michael Osipov wrote: Hi, we solved 17 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12350597 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/projects/MWAR/issues Staging repo: https://repository.apache.org/content/repositories/maven-1955/ https://repository.apache.org/content/repositories/maven-1955/org/apache/maven/plugins/maven-war-plugin/3.4.0/maven-war-plugin-3.4.0-source-release.zip Source release checksum(s): maven-war-plugin-3.4.0-source-release.zip sha512: ef7b2621697024570522a778318106f1e5ca18bf6944cb9e43e693e8c37312af272036f517d03b3555622f9bad695217ececa078affda6442d76063b5153f998 Staging site: https://maven.apache.org/plugins-archives/maven-war-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 Mit freundlichem Gruß Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Inhaber Dipl.Ing.(FH) Karl Heinz Marbaise USt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen https://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] POM model version
Le mer. 14 juin 2023 à 10:07, Guillaume Nodet a écrit : > I think this is exactly what Hervé explains was rejected years ago. The > assumption is that the POM v4 is "set in amber" and will never change, at > least for the consumer side, i.e. defining dependencies. For the build > side, it has to evolve, so the POM v5 will need a different schema url or > version. But imho the goals are: > * make sure we keep POM v4 the way it is to tools for consumers > * allow some room for POM v5 on the build side > > However, the problem I see is that when you deploy a "pom" package, i.e. a > parent POM that may be used as a parent for other projects, we clearly have > a problem for which I do not really have a clear understanding how to > solve. Let's assume this POM uses a POM v5 new feature, so that the > semantic data carried by this POM can not be written with a POM v4. Such a > POM can not be uploaded to maven central in the v4 form, so it WILL break > tools, but I don't really see any other way. > > So here's what I propose: > * further trim down the consumer POM as it was envisioned years ago in > [1] and [2] (the removed data will still be available for other tools to > consume, see below) > * we want to relax the constraints of the v4 pom schema a bit to be able > to validate the current build pom (where a few things are inferred) > Actually, the schema is already relaxed wrt to required elements. It's my IDE which must be doing additional validation because the schema looks good. * for packaged artifacts, we will upload the consumer POM v4 as the main > POM and the normalized POM v4/v5 as an attached artifact > * for the "pom" package, we will upload the normalized POM v4/v5 as the > main POM (no consumer POM) > Note that this would be problematic for BOM, which are pom but not used as parents. I wonder if we should clean-up this use case by using a specific "bom" packaging. This could also affect how the POM is transformed to a consumer-side BOM, as we could remove the dependencyManagement element from consumer packaged artifacts, but we'd need to keep it for consumer BOMs. > > In the short term we could then: > * allow the definition of POM v4.x, i.e. small evolutions with a schema > compatible to v4 (i.e. mostly new elements / attributes) that will give a > bit of freedom to implement new stuff (i.e. we should start properly > versioning it and communicate to the community that they will have to adapt > their tools) > * when deploying the v4/v5 POM as the main POM (i.e. for pom packages), > we could be smart enough to see if the POM requires non v4 features and if > that's not the case, upload it as a the lower version possible (i.e. POM > v4), thereby minimizing disruption for other tools scanning central (and > allow consumption with maven 3.x) > Longer term: > * define a POM v5+ schema (with GAV as attributes, etc...) > > Thoughts ? > > Guillaume > > [1] https://maven.apache.org/studies/consumer-pom/maven.html > [2] > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > > Le mer. 14 juin 2023 à 08:48, Hunter C Payne > a écrit : > >> Sorry for chiming in again but perhaps I might have an idea. The XSD >> schema that a POM uses is actually referenced from the POM. So in essence >> each POM carries with it what is needed to know to parse it. Perhaps in >> Maven 5 (or whichever version) we can require POM parsers to read and use >> the specific XSD schema referenced in the POM. That way you can have more >> room to try changes to the POM format. But there really should be a >> mechanism for pushing POM changes downstream and XSD seems like a good >> option for that. Sorry if this is already the plan and I'm repeating what >> is already known. >> >> Hunter >> >> On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy < >> herve.bout...@free.fr> wrote: >> >> Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit : >> > > Don't look at Maven code to judge: the whole logic is based on "known >> > > unknown" >> > > = we don't know who parses POMs published to Maven Central, but there >> are >> > > many >> > > (it's easy to cite many, but not all). >> > >> > I can't buy that argument. You're saying that we should not assume the >> way >> > the POM is parsed, but we assume they don't parse arguments. That's >> > clearly dodgy, and false for our own parser (both are parsed and >> rejected >> > in strict mode and silently ignored in lenient mode). >> >> I can understand that it does not match the precision of your logic based >> on >> todays code: did you look at Maven 2 code? did you look at every other >> consumer of Maven Central content? >> >> whatever you feel about it today, that's what has been defined and done >> for now >> more than 15 years, and proven working, and AFAIK checked when publishing >> to >> Maven Central >> >> If we change that, we are changing the Maven Central contract for >> everybody >> from the past and
JDK 21 is in Rampdown / The importance of testing with Early-Access Builds
Welcome to the OpenJDK Quality Outreach June update. JDK 21 has entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 21 stabilization repository. At this point, the overall JDK 21 feature set is frozen. Any changes pushed to the main line are now bound for JDK 22. The stabilization repository is open for select bug fixes and, with approval, late low-risk enhancements per the JDK Release Process [2]. And in contrast to past practice, most stabilization changes will be integrated via backports from the main-line repository [1]. The coming weeks are critical to identify and resolve as many issues as possible, i.e. before JDK 21 enters the Release Candidates phase in August. We need to make sure those few weeks are leveraged to test both existing code running on top of JDK 21 and new JDK 21 features. The heads-up below illustrates the importance and the benefits of doing such tests. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html [2] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements ## Heads-up: On the Importance of Doing Tests With OpenJDK Early-Access Builds The following is a recent example that demonstrates the benefits of testing an existing codebase using the OpenJDK early-access builds. Last month, we published a heads-up focused on Sequenced Collections [3] as they could potentially introduce some incompatibilities. The Eclipse Collections (EC) team did their homework and sure enough, EC was impacted as it was now throwing compilation errors with JDK 21 early-access builds. The EC team was able to quickly fix those compilation errors, i.e., it was mainly about adding overriding default methods. But once those compilation errors were fixed, and this is where it gets interesting, another issue surfaced. This time, the problem was related to LinkedHashMap serialization. After some investigation, the EC team identified that second issue as JDK one and a JBS ticket was opened. That issue was then confirmed as a JDK regression and was promptly fixed in OpenJDK main-line, i.e., JDK 22. The fix was then backported into the JDK 21 stabilization repository. This EC pull request [4] provides additional details. In this case, the JDK fix was easy but it is nevertheless the kind of issues that could have easily fallen through the crack if the EC team wasn’t pro-actively testing with OpenJDK early-access builds. The EC issue would have then surfaced after the JDK 21 General Availability... and who knows when the JDK LinkedHashMap serialization regression would have been fixed? TL; DR; Testing an existing codebase with OpenJDK early-access builds is a win-win situation. It helps the project itself, Eclipse Collections in this case, as it enables developers to identify issues in their own codebase before that new JDK version is Generally Available. It helps the JDK too as any JDK issue detected early enough in the development cycle gives the OpenJDK engineers a chance to address it before the General Availability of that new JDK version. And last but not least, having a robust JDK is also a win for the Java community at large. And thanks to the Eclipse Collections team and especially to Don Raab for helping to make the Java platform more robust! [3] https://inside.java/2023/05/12/quality-heads-up/ [4] https://github.com/eclipse/eclipse-collections/pull/1461 ## JDK 21 Early-Access Builds JDK 21 Early-Access builds 26 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6] and the javadocs here [7]. ### JEPs integrated into JDK 21: - 430: String Templates (Preview) - 431: Sequenced Collections - 439: Generational ZGC - 440: Record Patterns - 441: Pattern Matching for switch - 442: Foreign Function & Memory API (3rd Preview) - 443: Unnamed Patterns and Variables (Preview) - 444: Virtual Threads - 445: Unnamed Classes and Instance Main Methods (Preview) - 446: Scoped Values (Preview) - 448: Vector API (6th Incubator) - 449: Deprecate the Windows 32-bit x86 Port for Removal - 451: Prepare to Disallow the Dynamic Loading of Agents - 452: Key Encapsulation Mechanism API - 453: Structured Concurrency (Preview) It is worth mentioning that JEP 404 (Generational Shenandoah - Experimental) has been proposed to drop from JDK 21 [8]. ### Changes in recent JDK 21 builds (b23-b26) that may be of interest: Note that this is only a curated list of changes, make sure to check [9] for additional changes. - JDK-8298127: HSS/LMS Signature Verification - JDK-8305972: Update XML Security for Java to 3.0.2 - JDK-8308244: Installation of jdk rpm corrupts alternatives - JDK-8307990: jspawnhelper must close its writing side of a pipe before reading from it - JDK-8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates - JDK-8303530: Redefine JAXP Configuration File -
Re: [DISCUSS] POM model version
I think this is exactly what Hervé explains was rejected years ago. The assumption is that the POM v4 is "set in amber" and will never change, at least for the consumer side, i.e. defining dependencies. For the build side, it has to evolve, so the POM v5 will need a different schema url or version. But imho the goals are: * make sure we keep POM v4 the way it is to tools for consumers * allow some room for POM v5 on the build side However, the problem I see is that when you deploy a "pom" package, i.e. a parent POM that may be used as a parent for other projects, we clearly have a problem for which I do not really have a clear understanding how to solve. Let's assume this POM uses a POM v5 new feature, so that the semantic data carried by this POM can not be written with a POM v4. Such a POM can not be uploaded to maven central in the v4 form, so it WILL break tools, but I don't really see any other way. So here's what I propose: * further trim down the consumer POM as it was envisioned years ago in [1] and [2] (the removed data will still be available for other tools to consume, see below) * we want to relax the constraints of the v4 pom schema a bit to be able to validate the current build pom (where a few things are inferred) * for packaged artifacts, we will upload the consumer POM v4 as the main POM and the normalized POM v4/v5 as an attached artifact * for the "pom" package, we will upload the normalized POM v4/v5 as the main POM (no consumer POM) In the short term we could then: * allow the definition of POM v4.x, i.e. small evolutions with a schema compatible to v4 (i.e. mostly new elements / attributes) that will give a bit of freedom to implement new stuff (i.e. we should start properly versioning it and communicate to the community that they will have to adapt their tools) * when deploying the v4/v5 POM as the main POM (i.e. for pom packages), we could be smart enough to see if the POM requires non v4 features and if that's not the case, upload it as a the lower version possible (i.e. POM v4), thereby minimizing disruption for other tools scanning central (and allow consumption with maven 3.x) Longer term: * define a POM v5+ schema (with GAV as attributes, etc...) Thoughts ? Guillaume [1] https://maven.apache.org/studies/consumer-pom/maven.html [2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Le mer. 14 juin 2023 à 08:48, Hunter C Payne a écrit : > Sorry for chiming in again but perhaps I might have an idea. The XSD > schema that a POM uses is actually referenced from the POM. So in essence > each POM carries with it what is needed to know to parse it. Perhaps in > Maven 5 (or whichever version) we can require POM parsers to read and use > the specific XSD schema referenced in the POM. That way you can have more > room to try changes to the POM format. But there really should be a > mechanism for pushing POM changes downstream and XSD seems like a good > option for that. Sorry if this is already the plan and I'm repeating what > is already known. > > Hunter > > On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy < > herve.bout...@free.fr> wrote: > > Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit : > > > Don't look at Maven code to judge: the whole logic is based on "known > > > unknown" > > > = we don't know who parses POMs published to Maven Central, but there > are > > > many > > > (it's easy to cite many, but not all). > > > > I can't buy that argument. You're saying that we should not assume the > way > > the POM is parsed, but we assume they don't parse arguments. That's > > clearly dodgy, and false for our own parser (both are parsed and rejected > > in strict mode and silently ignored in lenient mode). > > I can understand that it does not match the precision of your logic based > on > todays code: did you look at Maven 2 code? did you look at every other > consumer of Maven Central content? > > whatever you feel about it today, that's what has been defined and done > for now > more than 15 years, and proven working, and AFAIK checked when publishing > to > Maven Central > > If we change that, we are changing the Maven Central contract for > everybody > from the past and future > > Maven 5 is not only about Maven: it's also about Maven Central, which is > the > hardest piece to make sure we don't break usage > > Regards, > > Hervé > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Guillaume Nodet
Re: [VOTE] Release Maven WAR Plugin version 3.4.0
+1 Am So., 11. Juni 2023 um 22:14 Uhr schrieb Michael Osipov : > > Hi, > > we solved 17 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12350597 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MWAR/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1955/ > https://repository.apache.org/content/repositories/maven-1955/org/apache/maven/plugins/maven-war-plugin/3.4.0/maven-war-plugin-3.4.0-source-release.zip > > Source release checksum(s): > maven-war-plugin-3.4.0-source-release.zip > sha512: > ef7b2621697024570522a778318106f1e5ca18bf6944cb9e43e693e8c37312af272036f517d03b3555622f9bad695217ececa078affda6442d76063b5153f998 > > Staging site: > https://maven.apache.org/plugins-archives/maven-war-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 > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven parent 40
+1 pon., 12 cze 2023 o 20:07 Slawomir Jaranowski napisał(a): > Hi, > > For testing you need ASF parent 30 from the staging repository. > > We solved 15 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12352681 > > Commits: > > https://github.com/apache/maven-parent/compare/maven-parent-39...maven-parent-40 > > Staging repo: > https://repository.apache.org/content/repositories/maven-1956/ > > https://repository.apache.org/content/repositories/maven-1956/org/apache/maven/maven-parent/40/maven-parent-40-source-release.zip > > Source release checksum(s): > maven-parent-40-source-release.zip - SHA-512 : > 8014f1b5b15b6e60d7d17077a3c853c40eff54385ab658ea102398129ad96fb1fc329c8b0130f52d7d05aff7a258e7d5cce0e02c9dfae40ed9427a8cb3ea7da1 > > Staging site: > https://maven.apache.org/pom-archives/maven-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski > -- Sławomir Jaranowski
Re: [DISCUSS] POM model version
Sorry for chiming in again but perhaps I might have an idea. The XSD schema that a POM uses is actually referenced from the POM. So in essence each POM carries with it what is needed to know to parse it. Perhaps in Maven 5 (or whichever version) we can require POM parsers to read and use the specific XSD schema referenced in the POM. That way you can have more room to try changes to the POM format. But there really should be a mechanism for pushing POM changes downstream and XSD seems like a good option for that. Sorry if this is already the plan and I'm repeating what is already known. Hunter On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy wrote: Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit : > > Don't look at Maven code to judge: the whole logic is based on "known > > unknown" > > = we don't know who parses POMs published to Maven Central, but there are > > many > > (it's easy to cite many, but not all). > > I can't buy that argument. You're saying that we should not assume the way > the POM is parsed, but we assume they don't parse arguments. That's > clearly dodgy, and false for our own parser (both are parsed and rejected > in strict mode and silently ignored in lenient mode). I can understand that it does not match the precision of your logic based on todays code: did you look at Maven 2 code? did you look at every other consumer of Maven Central content? whatever you feel about it today, that's what has been defined and done for now more than 15 years, and proven working, and AFAIK checked when publishing to Maven Central If we change that, we are changing the Maven Central contract for everybody from the past and future Maven 5 is not only about Maven: it's also about Maven Central, which is the hardest piece to make sure we don't break usage Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven WAR Plugin version 3.4.0
+1 On Mon, 12 Jun 2023 at 06:14, Michael Osipov wrote: > > Hi, > > we solved 17 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12350597 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MWAR/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1955/ > https://repository.apache.org/content/repositories/maven-1955/org/apache/maven/plugins/maven-war-plugin/3.4.0/maven-war-plugin-3.4.0-source-release.zip > > Source release checksum(s): > maven-war-plugin-3.4.0-source-release.zip > sha512: > ef7b2621697024570522a778318106f1e5ca18bf6944cb9e43e693e8c37312af272036f517d03b3555622f9bad695217ececa078affda6442d76063b5153f998 > > Staging site: > https://maven.apache.org/plugins-archives/maven-war-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 > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Invoker Plugin version 3.6.0
+1 Reproducible Builds ok: reference build done with JDK 8 on Windows System Requirements history not yet done: created https://issues.apache.org/jira/browse/MINVOKER-349 Contributions welcome, as this will be a prerequisite to change these prerequisites in the future Regards, Hervé On 2023/06/11 17:34:04 Michael Osipov wrote: > Hi, > > we solved 8 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317525=12353076 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINVOKER%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1954/ > https://repository.apache.org/content/repositories/maven-1954/org/apache/maven/plugins/maven-invoker-plugin/3.6.0/maven-invoker-plugin-3.6.0-source-release.zip > > Source release checksum(s): > maven-invoker-plugin-3.6.0-source-release.zip > sha512: > ed73a73536577de505c2c09b09ad644dcd4e1b957c785dc48d3481c67ba5f598ba5095d125d3d54414fde02226fb638536e1bcdc7618b23515d224184af3fdf2 > > Staging site: > https://maven.apache.org/plugins-archives/maven-invoker-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 > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] POM model version
Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit : > > Don't look at Maven code to judge: the whole logic is based on "known > > unknown" > > = we don't know who parses POMs published to Maven Central, but there are > > many > > (it's easy to cite many, but not all). > > I can't buy that argument. You're saying that we should not assume the way > the POM is parsed, but we assume they don't parse arguments. That's > clearly dodgy, and false for our own parser (both are parsed and rejected > in strict mode and silently ignored in lenient mode). I can understand that it does not match the precision of your logic based on todays code: did you look at Maven 2 code? did you look at every other consumer of Maven Central content? whatever you feel about it today, that's what has been defined and done for now more than 15 years, and proven working, and AFAIK checked when publishing to Maven Central If we change that, we are changing the Maven Central contract for everybody from the past and future Maven 5 is not only about Maven: it's also about Maven Central, which is the hardest piece to make sure we don't break usage Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven WAR Plugin version 3.4.0
+1 Reproducible Build ok: reference done with JDK 8 on Windows Regards, Hervé Le dimanche 11 juin 2023, 22:14:08 CEST Michael Osipov a écrit : > Hi, > > we solved 17 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121 > rsion=12350597 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MWAR/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1955/ > https://repository.apache.org/content/repositories/maven-1955/org/apache/mav > en/plugins/maven-war-plugin/3.4.0/maven-war-plugin-3.4.0-source-release.zip > > Source release checksum(s): > maven-war-plugin-3.4.0-source-release.zip > sha512: > ef7b2621697024570522a778318106f1e5ca18bf6944cb9e43e693e8c37312af272036f517d0 > 3b3555622f9bad695217ececa078affda6442d76063b5153f998 > > Staging site: > https://maven.apache.org/plugins-archives/maven-war-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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
