Re: Quo Vadis Maven?
Awesome work everyone. It is great to see all the progress Maven and related tooling is making. Manfred On 2024-04-23 2:12 p.m., Tamás Cservenák wrote: Howdy, This is just a short newsflash about upcoming planned releases related to Maven. Recently we got a huge spike in plugin releases, with various fixes and improvements. I will not enumerate all of them here, just use `mvn versions:display-plugin-updates` to pick them up ;) (and more plugins to come). What I do want to share is about our upcoming Maven releases... Maven 3.9.7 is nearing (read: coming soon), and will have an important Resolver update and other important fixes. Most importantly, the file-locks are getting nice improvement (feedback VERY welcome). Maven 3.9.7 issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 Resolver 1.9.19 issues (mostly bug fixes): https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 At the same time, we plan to release Maven Daemon (m39) as well, to have it aligned with Maven 3,9,7: with many bug fixes and improvements/alignments to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) interchangeable on workstations. Next, Maven 4 is turning beta, so the next release will be beta1! And again, same thing for Maven Damon (m40), we will have a release that will include Maven 4 beta-1. Maven 4 beta-1 https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1 release): https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 Keep your eyes on our upcoming releases, and have fun! - The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Quo Vadis Maven?
Howdy, This is just a short newsflash about upcoming planned releases related to Maven. Recently we got a huge spike in plugin releases, with various fixes and improvements. I will not enumerate all of them here, just use `mvn versions:display-plugin-updates` to pick them up ;) (and more plugins to come). What I do want to share is about our upcoming Maven releases... Maven 3.9.7 is nearing (read: coming soon), and will have an important Resolver update and other important fixes. Most importantly, the file-locks are getting nice improvement (feedback VERY welcome). Maven 3.9.7 issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 Resolver 1.9.19 issues (mostly bug fixes): https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 At the same time, we plan to release Maven Daemon (m39) as well, to have it aligned with Maven 3,9,7: with many bug fixes and improvements/alignments to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) interchangeable on workstations. Next, Maven 4 is turning beta, so the next release will be beta1! And again, same thing for Maven Damon (m40), we will have a release that will include Maven 4 beta-1. Maven 4 beta-1 https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1 release): https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 Keep your eyes on our upcoming releases, and have fun! - The Apache Maven team
[ANN] Apache Maven Shade Plugin 3.5.3 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 3.5.3 This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. https://maven.apache.org/plugins/maven-shade-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-shade-plugin 3.5.3 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-shade-plugin/download.cgi Release Notes - Maven Shade Plugin - Version 3.5.3 ** Bug * [MSHADE-471] - still timestamp issues with timezones (DST) ** Task * [MSHADE-472] - upgrade parent POM ** Dependency upgrade * [MSHADE-470] - Upgrade ASM to 9.7 (Java 23) 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 Apache Maven Shade Plugin version 3.5.3
Hi, The vote has passed with the following result: +1 : zhongming hua, Olivier Lamy, Romain Manni-Bucau, Hervé Boutemy PMC quorum reached I will promote the source release zip file to Apache distribution area and the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.3
here is my +1 Reproducible Build ok: reference build done with JDK 17 on *nix Regards, Hervé On 2024/04/20 15:54:37 Hervé Boutemy wrote: > Hi, > > We solved 3 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12354342=Text > > Staging repo: > https://repository.apache.org/content/repositories/maven-2096/ > https://repository.apache.org/content/repositories/maven-2096/org/apache/maven/plugins/maven-shade-plugin/3.5.3/maven-shade-plugin-3.5.3-source-release.zip > > Source release checksum(s): > maven-shade-plugin-3.5.3-source-release.zip sha512: > a97d291f66f7f4a96af936c27061305e3856cb1e32ee5130cbf9b2f9a31d2ac7c1551ab17cd41e75887ac2345b815fad248fb381f437bf1376467a4fcdf24544 > > 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 > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven Doxia Sitetools version 2.0.0-M18
Hi, we solved 12 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12354412 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open Staging repo: https://repository.apache.org/content/repositories/maven-2098 https://repository.apache.org/content/repositories/maven-2098/org/apache/maven/doxia/doxia-sitetools/2.0.0-M18/doxia-sitetools-2.0.0-M18-source-release.zip Source release checksum(s): doxia-sitetools-2.0.0-M18-source-release.zip sha512: 93247b25edb430485e26f634a3d9686182e125ff4ac3b2490274a7f97961e97d4d38b6fd8bd85a2378131ed55d0caadcd6902b4e5156937a00c7bc98eb3c36a4 Staging site: https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-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 Apache Maven Wrapper 3.3.1
+1 On Tue, 23 Apr 2024 at 02:28, Tamás Cservenák wrote: > > Howdy, > > The importance of this release is to gain over 3.3.0: Two changes are in > this release, both are equally important, but MWRAPPER-134 adds simple > means for tooling to discover wrapper versions being used. With 3.3.0 we > lost this ability to figure out wrapper versions easily. > > We solved 2 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12354586 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MWRAPPER/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-2097 > > Source release checksum SHA512: > 270d843df1b5db108f5420c3ef9310ff1238d49b077c35cff6a5eca9f584f6f41ee9d82cba169fce2c6e768281cda9d84383ec75171640163d0966cc0f206949 > > Staging site: > https://maven.apache.org/wrapper-archives/wrapper-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: Replacement proposal for
Le 2024-04-23 à 10 h 21, sebb a écrit : Minor correction: the classes method will necessarily *detect* added sources, because they won't have a class file. What occurs as a result is another matter./ It might be worth considering forcing a full build as an option in such cases if there is any way that adding a new source file can affect the compilation of others. Yes, I was thinking about one more value for , maybe "rebuildOnAdd". The current Maven 3 plugin has an implicit "rebuild on add" behavior when is true, but not when it is false. Martin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Replacement proposal for
Minor correction: the classes method will necessarily *detect* added sources, because they won't have a class file. What occurs as a result is another matter./ It might be worth considering forcing a full build as an option in such cases if there is any way that adding a new source file can affect the compilation of others. On Mon, 22 Apr 2024 at 13:52, Martin Desruisseaux wrote: > > Hello all > > The Maven compiler plugin has an boolean > parameter with `true` as the default value. This parameter has issues > discussed in MCOMPILER-209 [1], which has 61 votes. In short, builds are > much faster when this parameter is set to `false`, which is > counter-intuitive. During the refactoring for the Maven 4 compiler > plugin, by looking at the source code, I saw the following issues with > the current implementation: > > * When is enabled (which is the default), > the plugin compares the list of source files in the current build > with a list saved after the previous build in order to detect > changes. But it seems to me that the plugin uses relative paths in > one case, and absolute paths in the other cases. Consequently, the > paths do not match and the plugin always thinks that all source > files changed. I did not double-checked or tested (maybe I missed > some `toAbsoluteFile()` calls). But if confirmed, it would explain > the MCOMPILER-209 issue. > * The ways that the two lists are compared has a performance cost of > O(N²). It could easily be O(N) instead by replacing one list by an > hash set. > * The plugin tries to detect changes in dependencies, but the > algorithm works only if the compilation never fail. Consider the > following scenario: > o One project has 3 modules: A, B and C. > o Module B and C depends on A. > o Developer makes a change in A and run `mvn install`. > o Module A compiles successfully, but B fails because of the > change in A. > o Developer fixes the build failure in B and run `mvn install` > again. In this scenario, the incremental compilation will not > see that C also needs to be rebuilt, because when > is enabled, the plugin compares the > JAR timestamps with the build start time. In this scenario, the > second build start time is after the `A.jar` creation time. > Maybe this issue was unnoticed because the issue explained in > the first bullet point caused the plugin to always recompile > everything anyway. > > I propose to deprecate in Maven 4 and > replace it by a new parameter: . Its value would > be a comma-separated list of values instead of a single boolean flag. > Those values specify which methods to use for deciding which files to > recompile: > > * "sources": check for changes in source files, including whether a > file has been deleted. This method uses a file saved by the previous > build in the "target/maven-status" directory (as done by the > current implementation). > * "classes": check whether the source file is more recent than the > class file. This method does not need any "maven-status" file from > the previous build, but does not detect whether a file has been > added or removed. > * "dependencies": check whether a dependency has changed (using a more > robust algorithm than the current one). > * "modules": do not specify any file to the compiler and use the > `--module` option instead, in which case the compiler will scan the > directories itself and decides itself which files to recompile based > on their timestamp. This option is available for modular projects only. > > The current boolean flag maps to above > proposal as below: > > * `true` is approximately equivalent to "sources,dependencies", except > that I propose to not rebuild everything when a file is added (it is > usually not needed). > * `false` is equivalent to "classes". > > As seen from above, the current actually > mixes two aspects that could be treated separately: whether to check if > a dependency changed, and whether to use a list saved from the previous > build for checking if a source file changed. The comma-separated value > proposal would allow users to control those aspects independently. > > Martin > > [1]https://issues.apache.org/jira/browse/MCOMPILER-209 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
