JDK 18: Rampdown Phase 1 & Early-Access builds 27
Robert, Thank you for being part of the OpenJDK Quality Outreach Program. As year-end 2021 approaches, I'd like to share some updates on JDK 18, which is scheduled for General Availability on March 22, 2022. JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 18 stabilization repository. At this point, the overall JDK 18 feature set is now frozen and no additional JEPs will be targeted to JDK 18. Only low-risk enhancements that add small bits of missing functionality or improve usability might still be considered. The next few weeks should be leveraged to try to identify and resolve as many issues as possible (i.e. before JDK 18 enters the Release Candidates phase). And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for issues that were reported by you! So thank you for your help contributing to the overall quality of OpenJDK! [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html ## JEP 400 - UTF-8 by Default All JEPs are now integrated, but we would like to draw your attention to JEP 400 especially if you are deploying on Windows as it might induce some incompatible behavior on that platform. JEP 400 [2] is changing the default charset to UTF-8. This aligns with the existing `newBufferedReader`/`Writer` methods of the `java.nio.file.Files` class where UTF-8 is the default when no explicit charset is set. By making UTF-8 the default charset, the JDK I/O APIs will now always work in the same, predictable manner, with no need to pay attention to the host and or user’s environment! Further, we encourage you to test your project(s) with the latest JDK 18 Early Access builds. We don't expect issues on macOS and Linux as their default encoding is already UTF-8. On Windows, especially for East Asian locales such as Chinese/Japanese/Korean, some incompatible behavior could be anticipated. If that’s the case, please consider a mitigation strategy [3]. [2] https://openjdk.java.net/jeps/400 [3] https://inside.java/2021/10/04/the-default-charset-jep400/ ## JDK 18 JDK 18 Early-Access builds 27 are now available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. Make sure to check the Release Notes [5]. As usual, we encourage you to test your project(s) using those EA builds and provide us feedback. [4] https://jdk.java.net/18/ [5] https://jdk.java.net/18/release-notes ### JEPs integrated to JDK 18: - JEP 400: UTF-8 by Default - JEP 408: Simple Web Server - JEP 413: Code Snippets in Java API Documentation - JEP 416: Reimplement Core Reflection with Method Handles - JEP 417: Vector API (Third Incubator) - JEP 418: Internet-Address Resolution SPI - JEP 419: Foreign Function & Memory API (Second Incubator) - JEP 420: Pattern Matching for switch (Second Preview) - JEP 421: Deprecate Finalization for Removal ### Changes in recent builds that maybe of interest: Build 27: - JDK-8266435: WBMPImageReader.read() should not truncate the input stream [Reported by PDFBox] - JDK-8278078: Cannot reference super before supertype constructor has been called - JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST - JDK-8277965: Enclosing instance optimization affects serialization - JDK-8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh() - JDK-8225181: KeyStore should have a getAttributes method - JDK-8275082: Update XML Security for Java to 2.3.0 - JDK-8278270: ServerSocket is not thread safe - JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets Build 26: - JDK-8277451: j.l.r.Field::set on static field with invalid argument type should throw IAE [Reported by Hibernate & ByteBuddy] - JDK-8258117: jar tool sets the time stamp of module-info.class entries to the current time [Reported by Apache Maven] - JDK-8268743: Require a better way for copying data between MemorySegments and on-heap arrays [Reported by Apache Lucene] - JDK-8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime [Reported by Apache Ant] - JDK-8277861: Terminally deprecate Thread.stop - JDK-8276665: ObjectInputStream.GetField.get(name, object) should throw ClassNotFoundException - JDK-8271623: Omit enclosing instance fields from inner classes that don't use it - JDK-8231107: Allow store password to be null when saving a PKCS12 KeyStore - JDK-8193682: Infinite loop in ZipOutputStream.close() - JDK-8277459: Add `jwebserver` tool [see Topics of Interest] Build 25: - JDK-8259643: ZGC can return metaspace OOM prematurely - JDK-8277212: GC accidentally cleans valid megamorphic vtable inline caches - JDK-8276970: Default charset for PrintWriter that wraps PrintStream - JDK-8272773: Configurable card table card size - JDK-4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath Build 24: - JDK-8275056: Allow G1 heap regions
Re: reviewing Maven Wrapper before releasing
thank you to everybody who reviewed, discussed, contributed we now have 16 issues fixed, everything seems stable if nobody objects, I'll start a release over the week-end Regards, Hervé Le mardi 7 décembre 2021, 00:07:41 CET Hervé BOUTEMY a écrit : > Hi, > > Maven Wrapper has been donated to Apache Maven, imported to > https://github.com/apache/maven-wrapper > > Documentation published to https://maven.apache.org/wrapper/ > > Here is the list of fixes from previous 0.5.6 release: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721 > rsion=12350068 > > > Please test and review so we can do a release soon > > Regards, > > Hervé > > > > - > 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
[GitHub] [maven-gh-actions-shared] slachiewicz merged pull request #24: Improve verification of site building
slachiewicz merged pull request #24: URL: https://github.com/apache/maven-gh-actions-shared/pull/24 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] hboutemy merged pull request #219: Add 'What's New in Maven 4' blog
hboutemy merged pull request #219: URL: https://github.com/apache/maven-site/pull/219 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] hboutemy merged pull request #275: Version requirement for versions before next major release
hboutemy merged pull request #275: URL: https://github.com/apache/maven-site/pull/275 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] hboutemy merged pull request #278: Fix url syntax for javaalmanac.io
hboutemy merged pull request #278: URL: https://github.com/apache/maven-site/pull/278 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] hboutemy commented on pull request #278: Fix url syntax for javaalmanac.io
hboutemy commented on pull request #278: URL: https://github.com/apache/maven-site/pull/278#issuecomment-990245367 stupid me: thank you :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] hboutemy merged pull request #277: Added Bytesafe to Available Repository Managers
hboutemy merged pull request #277: URL: https://github.com/apache/maven-site/pull/277 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-gh-actions-shared] slawekjaranowski opened a new pull request #24: Improve verification of site building
slawekjaranowski opened a new pull request #24: URL: https://github.com/apache/maven-gh-actions-shared/pull/24 - add site build to fail-fast-build - build site with profile reporting - skip test during site build, it is done in the same workspace so report from test execution will be present -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] niclas-g opened a new pull request #277: Added Bytesafe to Available Repository Managers
niclas-g opened a new pull request #277: URL: https://github.com/apache/maven-site/pull/277 Added a link to Bytesafe which has support for Maven -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Am 2021-12-07 um 09:47 schrieb Guillaume Nodet: Following the recent work done to integrate the maven caching / incremental build system into maven, I think it's now time to discuss where we want its long-term location to be. This extension was donated a few months ago and provides local and remote caching of maven project's output, based on computed hashes of the inputs. It's defined as a maven extension and can be used as a core or build extension. This avoids building the project and speeds up builds a lot ! The current status of this work resides in 3 branches: * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622) * MNG-7129-master (PR at https://github.com/apache/maven/pull/607) * https://github.com/apache/maven/tree/MNG-7129-maven-caching The two first PRs include the required changes to integrate the extension in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the one that should be moved to a separate repository and contain the code for the extension. The goal is to agree on the location and the final name for the repository (it can't be changed easily). I propose maven-caching as the repository / subproject name, but any better name is welcomed of course. I dislike the name 'maven-caching' because it is very very generic. What does it cache? Just like we have Maven Artifact Resolver. The name should tell what it caches, e.g., maven-build-cache/caching/cacher, or maven-incremental-build... Consider that the Maven local repository is also called Maven local artifact repo cache, etc. M - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY a écrit : > we have most plugins that are simple with only 1 mono-module build > This makes documentation easy in /plugins/maven-*-plugin/: > see https://maven.apache.org/components/plugins/ for full list > > we have a few components that have a plugin as part of a larger > multi-module > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer, > release, and > soon wrapper > > And from experience, it makes documentation harder because there is always > the > question of what to write in the plugin pages and what to write in other > modules. Not talking of navigation from /plugins/maven-xxx-plugin to /xxx/ > maven-xxx-plugin (we have a trick for redirecting...) > > In caching case, I see that there is only one submodule, that is done for > ITs > with Surefire: is it necessary? isn't maven-invoker-plugin usable, like > for > plugins? > Yes, that's actually a good point. I thought about that when I read Tamás answer. I'll double check if the integration tests can be merged into a single module. > > Regards, > > Hervé > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit : > > I think the repository name should not contain 'extension', similar to > > surefire which provides a plugin, but it a bit more complex > > The fact that it is provided as an extension is a technicality in this > case > > imho. > > No big deal though... > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák a > écrit : > > > Howdy, > > > > > > I'd rather group ASF extensions (are there any existing ones aside of > > > caching?), > > > to be clear... so GH repo could be something like > > > apache/maven-caching-extension > > > apache/maven-foobar-extension > > > etc? > > > > > > T > > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet > wrote: > > > > Following the recent work done to integrate the maven caching / > > > > > > incremental > > > > > > > build system into maven, I think it's now time to discuss where we > want > > > > > > its > > > > > > > long-term location to be. > > > > > > > > This extension was donated a few months ago and provides local and > > > > remote > > > > caching of maven project's output, based on computed hashes of the > > > > > > inputs. > > > > > > > It's defined as a maven extension and can be used as a core or build > > > > extension. This avoids building the project and speeds up builds a > lot > > > > ! > > > > > > > > The current status of this work resides in 3 branches: > > > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622) > > > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607) > > > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching > > > > > > > > The two first PRs include the required changes to integrate the > > > > extension > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is > the > > > > > > one > > > > > > > that should be moved to a separate repository and contain the code > for > > > > > > the > > > > > > > extension. The goal is to agree on the location and the final name > for > > > > > > the > > > > > > > repository (it can't be changed easily). > > > > > > > > I propose maven-caching as the repository / subproject name, but any > > > > > > better > > > > > > > name is welcomed of course. > > > > > > > > -- > > > > > > > > Guillaume Nodet > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Guillaume Nodet
Re: [DISCUSS] Move maven caching to an external repository
we have most plugins that are simple with only 1 mono-module build This makes documentation easy in /plugins/maven-*-plugin/: see https://maven.apache.org/components/plugins/ for full list we have a few components that have a plugin as part of a larger multi-module build, like surefire, jxr, archetype, scm, plugin-tools, enforcer, release, and soon wrapper And from experience, it makes documentation harder because there is always the question of what to write in the plugin pages and what to write in other modules. Not talking of navigation from /plugins/maven-xxx-plugin to /xxx/ maven-xxx-plugin (we have a trick for redirecting...) In caching case, I see that there is only one submodule, that is done for ITs with Surefire: is it necessary? isn't maven-invoker-plugin usable, like for plugins? Regards, Hervé Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit : > I think the repository name should not contain 'extension', similar to > surefire which provides a plugin, but it a bit more complex > The fact that it is provided as an extension is a technicality in this case > imho. > No big deal though... > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák a écrit : > > Howdy, > > > > I'd rather group ASF extensions (are there any existing ones aside of > > caching?), > > to be clear... so GH repo could be something like > > apache/maven-caching-extension > > apache/maven-foobar-extension > > etc? > > > > T > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet wrote: > > > Following the recent work done to integrate the maven caching / > > > > incremental > > > > > build system into maven, I think it's now time to discuss where we want > > > > its > > > > > long-term location to be. > > > > > > This extension was donated a few months ago and provides local and > > > remote > > > caching of maven project's output, based on computed hashes of the > > > > inputs. > > > > > It's defined as a maven extension and can be used as a core or build > > > extension. This avoids building the project and speeds up builds a lot > > > ! > > > > > > The current status of this work resides in 3 branches: > > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622) > > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607) > > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching > > > > > > The two first PRs include the required changes to integrate the > > > extension > > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the > > > > one > > > > > that should be moved to a separate repository and contain the code for > > > > the > > > > > extension. The goal is to agree on the location and the final name for > > > > the > > > > > repository (it can't be changed easily). > > > > > > I propose maven-caching as the repository / subproject name, but any > > > > better > > > > > name is welcomed of course. > > > > > > -- > > > > > > Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: reviewing Maven Wrapper before releasing
awesome. Thanks On Thu, Dec 9, 2021 at 12:43 AM Hervé BOUTEMY wrote: > this is the fix in https://issues.apache.org/jira/browse/MWRAPPER-18 > > with wrapper 0.5.6, there was a fixed Maven version hard coded in maven- > wrapper.jar and inconsistent local installation directory name (see Jira > issue > for detailed description) > > with MWRAPPER-18, from the distributionUrl in maven-wrapper.properties, it > replaces the repository prefix: see the commit > > Regards, > > Hervé > > Le jeudi 9 décembre 2021, 09:19:09 CET Dan Tran a écrit : > > That works, but how does it figure out the maven version to compute the > > full URL to download? > > > > Thanks > > > > -D > > > > On Wed, Dec 8, 2021 at 11:10 PM Hervé BOUTEMY > wrote: > > > there is MVNW_REPOURL system property > > > https://maven.apache.org/wrapper/#Using_a_Maven_Repository_Manager > > > > > > with a fix done in https://issues.apache.org/jira/browse/MWRAPPER-18 > > > (showing concrete usage output) > > > > > > Is it what you expected? > > > > > > Regards, > > > > > > Hervé > > > > > > Le jeudi 9 décembre 2021, 00:59:41 CET Dan Tran a écrit : > > > > sorry for hi-jack this thread. is it possible to configure mvnw to > use > > > > a > > > > new location of distributionUrl on the fly? (without touching > > > > maven-wrapper.properties) > > > > > > > > Thanks > > > > > > > > -D > > > > > > > > On Wed, Dec 8, 2021 at 11:31 AM Slawomir Jaranowski < > > > > > > s.jaranow...@gmail.com> > > > > > > > wrote: > > > > > In current project configuration it is a bug rather ... We can use > a > > > > > wrapper with java 5 but we can't install it because the plugin > > > > > requires > > > > > java 8 ... > > > > > > > > > > śr., 8 gru 2021 o 20:18 Xeno Amess > napisał(a): > > > > > > +1 for forcing more people quit java 5,6,7， as even 17 is out. > > > > > > 8 is the minimum version normal people can accept，others be > zombies > > > > > > who > > > > > > > > do > > > > > > > > > > > not need to be maintained IMO. They can use original wrapper > plugin > > > > > > > > > > anyway. > > > > > > > > > > > If we do not force them when beginning，it is harder to add the > > > > > > liminition > > > > > > later. > > > > > > > > > > > > XenoAmess > > > > > > > > > > > > From: Slawomir Jaranowski > > > > > > Sent: Thursday, December 9, 2021 3:11:42 AM > > > > > > To: Maven Developers List > > > > > > Subject: Re: reviewing Maven Wrapper before releasing > > > > > > > > > > > > I created issues with the proposition of improvement: > > > > > > > > > > > > https://issues.apache.org/jira/browse/MWRAPPER-31 > > > > > > https://issues.apache.org/jira/browse/MWRAPPER-32 > > > > > > https://issues.apache.org/jira/browse/MWRAPPER-33 > > > > > > > > > > > > please assign a version to fix ... if it is applicable. > > > > > > > > > > > > śr., 8 gru 2021 o 19:47 Hervé BOUTEMY > > > > > > > > > > napisał(a): > > > > > > > because it's as it was imported: > > > > > > > > https://github.com/takari/maven-wrapper/blob/master/pom.xml#L21 > > > > > > > I refactored but kept everything as equivalent as possible > > > > > > > > > > > > > > we can update the value if it has an interest, with associated > > > > > > > Jira > > > > > > > > > > issue > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Hervé > > > > > > > > > > > > > > Le mercredi 8 décembre 2021, 19:14:55 CET Slawomir Jaranowski a > > > > > > écrit > > > > > > > > > > > Next question: > > > > > > > > - why use java 5 in maven-wrapper module .. it is not > possible > > > > > > > > build > > > > > > > > > > > > > > with > > > > > > > > > > > > > > > java > 8 [1] > > > > > > > > > > > > > > > > [1] > > > > > > > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-wrapper/job/ > > > > > > > > ma> > > > > > > > > > > > > > ster/ > > > > > > > > śr., 8 gru 2021 o 19:05 Hervé BOUTEMY > > > > > > > > > > > > > > > napisał(a): > > > > > > > > > Le mercredi 8 décembre 2021, 15:52:46 CET Robert Scholte a > > > > > > écrit : > > > > > > > > > > With mvn verify -Prun-its all ITs fail on my system. This > > > > > > should > > > > > > > > > work > > > > > > > > > > > > > > > > out-of-the-box, so I'll need to investigate the issue. > > > > > > > > > > > > > > > > > > > > And I'm pretty sure we can remove the cli package: you > can't > > > > > > > > > > pass > > > > > > > > > > > > > > System > > > > > > > > > > > > > > > > > properties to Maven, only arguments. And they should be > > > > > > passed > > > > > > > > > > > > > as > > > > > > > > > > > > is > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > mvn. > > > > > > > > > > > > > > > > > > I must admit I don't know: I suppose that if the code is > here > > > > > > from > > > > > > > > > the > > > > > > > > > > > > > > > beginning, it's for some use, it's just me who did not > imagine > > > > > > the > > > > > > > > > use > > > > > > > > > > > > > > > case > > > > > > > > > > > > > > > > > > if everybody is confident that
Re: reviewing Maven Wrapper before releasing
this is the fix in https://issues.apache.org/jira/browse/MWRAPPER-18 with wrapper 0.5.6, there was a fixed Maven version hard coded in maven- wrapper.jar and inconsistent local installation directory name (see Jira issue for detailed description) with MWRAPPER-18, from the distributionUrl in maven-wrapper.properties, it replaces the repository prefix: see the commit Regards, Hervé Le jeudi 9 décembre 2021, 09:19:09 CET Dan Tran a écrit : > That works, but how does it figure out the maven version to compute the > full URL to download? > > Thanks > > -D > > On Wed, Dec 8, 2021 at 11:10 PM Hervé BOUTEMY wrote: > > there is MVNW_REPOURL system property > > https://maven.apache.org/wrapper/#Using_a_Maven_Repository_Manager > > > > with a fix done in https://issues.apache.org/jira/browse/MWRAPPER-18 > > (showing concrete usage output) > > > > Is it what you expected? > > > > Regards, > > > > Hervé > > > > Le jeudi 9 décembre 2021, 00:59:41 CET Dan Tran a écrit : > > > sorry for hi-jack this thread. is it possible to configure mvnw to use > > > a > > > new location of distributionUrl on the fly? (without touching > > > maven-wrapper.properties) > > > > > > Thanks > > > > > > -D > > > > > > On Wed, Dec 8, 2021 at 11:31 AM Slawomir Jaranowski < > > > > s.jaranow...@gmail.com> > > > > > wrote: > > > > In current project configuration it is a bug rather ... We can use a > > > > wrapper with java 5 but we can't install it because the plugin > > > > requires > > > > java 8 ... > > > > > > > > śr., 8 gru 2021 o 20:18 Xeno Amess napisał(a): > > > > > +1 for forcing more people quit java 5,6,7， as even 17 is out. > > > > > 8 is the minimum version normal people can accept，others be zombies > > > > who > > > > > > do > > > > > > > > > not need to be maintained IMO. They can use original wrapper plugin > > > > > > > > anyway. > > > > > > > > > If we do not force them when beginning，it is harder to add the > > > > > liminition > > > > > later. > > > > > > > > > > XenoAmess > > > > > > > > > > From: Slawomir Jaranowski > > > > > Sent: Thursday, December 9, 2021 3:11:42 AM > > > > > To: Maven Developers List > > > > > Subject: Re: reviewing Maven Wrapper before releasing > > > > > > > > > > I created issues with the proposition of improvement: > > > > > > > > > > https://issues.apache.org/jira/browse/MWRAPPER-31 > > > > > https://issues.apache.org/jira/browse/MWRAPPER-32 > > > > > https://issues.apache.org/jira/browse/MWRAPPER-33 > > > > > > > > > > please assign a version to fix ... if it is applicable. > > > > > > > > > > śr., 8 gru 2021 o 19:47 Hervé BOUTEMY > > > > > > > > napisał(a): > > > > > > because it's as it was imported: > > > > > > https://github.com/takari/maven-wrapper/blob/master/pom.xml#L21 > > > > > > I refactored but kept everything as equivalent as possible > > > > > > > > > > > > we can update the value if it has an interest, with associated > > > > > > Jira > > > > > > > > issue > > > > > > > > > > Regards, > > > > > > > > > > > > Hervé > > > > > > > > > > > > Le mercredi 8 décembre 2021, 19:14:55 CET Slawomir Jaranowski a > > > > écrit > > > > > > > > > Next question: > > > > > > > - why use java 5 in maven-wrapper module .. it is not possible > > > > > > > build > > > > > > > > > > > > with > > > > > > > > > > > > > java > 8 [1] > > > > > > > > > > > > > > [1] > > > > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-wrapper/job/ > > > > > > ma> > > > > > > > > > > > ster/ > > > > > > > śr., 8 gru 2021 o 19:05 Hervé BOUTEMY > > > > > > > > > > > > napisał(a): > > > > > > > > Le mercredi 8 décembre 2021, 15:52:46 CET Robert Scholte a > > > > écrit : > > > > > > > > > With mvn verify -Prun-its all ITs fail on my system. This > > > > should > > > > > > > work > > > > > > > > > > > > > > out-of-the-box, so I'll need to investigate the issue. > > > > > > > > > > > > > > > > > > And I'm pretty sure we can remove the cli package: you can't > > > > > > > > > pass > > > > > > > > > > > > System > > > > > > > > > > > > > > > properties to Maven, only arguments. And they should be > > > > passed > > > > > > > > > > > as > > > > > > > > > > is > > > > > > > > > > > to > > > > > > > > > > > > > > > mvn. > > > > > > > > > > > > > > > > I must admit I don't know: I suppose that if the code is here > > > > from > > > > > > > the > > > > > > > > > > > > > beginning, it's for some use, it's just me who did not imagine > > > > the > > > > > > > use > > > > > > > > > > > > > case > > > > > > > > > > > > > > > > if everybody is confident that it's never used, no problem to > > > > > > > > remove > > > > > > > > > it > > > > > > > > > > > > > > IT's should confirm that. > > > > > > > > > > > > > > > > > > Robert > > > > > > > > > > > > > > > > > > -- Origineel bericht -- > > > > > > > > > Van: "Jason van Zyl" > > > > > > > > > Aan: "Maven Developers List" > > > > > > > > > Verzonden:
Re: reviewing Maven Wrapper before releasing
That works, but how does it figure out the maven version to compute the full URL to download? Thanks -D On Wed, Dec 8, 2021 at 11:10 PM Hervé BOUTEMY wrote: > there is MVNW_REPOURL system property > https://maven.apache.org/wrapper/#Using_a_Maven_Repository_Manager > > with a fix done in https://issues.apache.org/jira/browse/MWRAPPER-18 > (showing concrete usage output) > > Is it what you expected? > > Regards, > > Hervé > > Le jeudi 9 décembre 2021, 00:59:41 CET Dan Tran a écrit : > > sorry for hi-jack this thread. is it possible to configure mvnw to use a > > new location of distributionUrl on the fly? (without touching > > maven-wrapper.properties) > > > > Thanks > > > > -D > > > > On Wed, Dec 8, 2021 at 11:31 AM Slawomir Jaranowski < > s.jaranow...@gmail.com> > > wrote: > > > In current project configuration it is a bug rather ... We can use a > > > wrapper with java 5 but we can't install it because the plugin requires > > > java 8 ... > > > > > > śr., 8 gru 2021 o 20:18 Xeno Amess napisał(a): > > > > +1 for forcing more people quit java 5,6,7， as even 17 is out. > > > > 8 is the minimum version normal people can accept，others be zombies > who > > > > > > do > > > > > > > not need to be maintained IMO. They can use original wrapper plugin > > > > > > anyway. > > > > > > > If we do not force them when beginning，it is harder to add the > > > > liminition > > > > later. > > > > > > > > XenoAmess > > > > > > > > From: Slawomir Jaranowski > > > > Sent: Thursday, December 9, 2021 3:11:42 AM > > > > To: Maven Developers List > > > > Subject: Re: reviewing Maven Wrapper before releasing > > > > > > > > I created issues with the proposition of improvement: > > > > > > > > https://issues.apache.org/jira/browse/MWRAPPER-31 > > > > https://issues.apache.org/jira/browse/MWRAPPER-32 > > > > https://issues.apache.org/jira/browse/MWRAPPER-33 > > > > > > > > please assign a version to fix ... if it is applicable. > > > > > > > > śr., 8 gru 2021 o 19:47 Hervé BOUTEMY > > > > > > napisał(a): > > > > > because it's as it was imported: > > > > > https://github.com/takari/maven-wrapper/blob/master/pom.xml#L21 > > > > > I refactored but kept everything as equivalent as possible > > > > > > > > > > we can update the value if it has an interest, with associated Jira > > > > > > issue > > > > > > > > Regards, > > > > > > > > > > Hervé > > > > > > > > > > Le mercredi 8 décembre 2021, 19:14:55 CET Slawomir Jaranowski a > écrit > : > > > > > > Next question: > > > > > > - why use java 5 in maven-wrapper module .. it is not possible > > > > > > build > > > > > > > > > > with > > > > > > > > > > > java > 8 [1] > > > > > > > > > > > > [1] > > > > > > > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-wrapper/job/ > > > ma> > > > > > > ster/ > > > > > > śr., 8 gru 2021 o 19:05 Hervé BOUTEMY > > > > > > > > > > napisał(a): > > > > > > > Le mercredi 8 décembre 2021, 15:52:46 CET Robert Scholte a > écrit : > > > > > > > > With mvn verify -Prun-its all ITs fail on my system. This > should > > > > > > > > work > > > > > > > > > > > > out-of-the-box, so I'll need to investigate the issue. > > > > > > > > > > > > > > > > And I'm pretty sure we can remove the cli package: you can't > > > > > > > > pass > > > > > > > > > > System > > > > > > > > > > > > > properties to Maven, only arguments. And they should be > passed > > > > > > > > as > > > > > > > > is > > > > > > > > > to > > > > > > > > > > > > > mvn. > > > > > > > > > > > > > > I must admit I don't know: I suppose that if the code is here > from > > > > > > > > the > > > > > > > > > > > beginning, it's for some use, it's just me who did not imagine > the > > > > > > > > use > > > > > > > > > > > case > > > > > > > > > > > > > > if everybody is confident that it's never used, no problem to > > > > > > remove > > > > > > > it > > > > > > > > > > > > IT's should confirm that. > > > > > > > > > > > > > > > > Robert > > > > > > > > > > > > > > > > -- Origineel bericht -- > > > > > > > > Van: "Jason van Zyl" > > > > > > > > Aan: "Maven Developers List" > > > > > > > > Verzonden: 7-12-2021 14:55:32 > > > > > > > > Onderwerp: Re: reviewing Maven Wrapper before releasing > > > > > > > > > > > > > > > > >Everything builds and it generates the wrapper for a > project in > > > > > > a > > > > > > > > way > > > > > > > > > > > > will > > > > > > > > > > > > > > > >be familiar to existing users. The switch for current users > > > > > > > > should, > > > > > > > > > > > > >hopefully, be painless and transparent. > > > > > > > > > > > > > > > > > >Nice work Robert and Hervé. I put a notice on the GitHub > page > > > > > > for > > > > > > > > the > > > > > > > > > > > > > >Takari version about the impending release at Apache, and > > > > > > provided > > > > > > > > > > > >pointers to the new Git repository and JIRA project. > > > > > > > > > > > > > > > > > >jvz > > > > > > > > > > > > > > > > > >> On Dec 6, 2021, at 6:07 PM,
Re: [DISCUSS] Move maven caching to an external repository
s/scp/scm Sorry T On Thu, Dec 9, 2021 at 9:04 AM Tamás Cservenák wrote: > Howdy, > > yes, like maven-scm, that contains m-scp-p among other things, but there > is complete scm codebase (while m-scp-p merely "invokes" it), also, there > are examples of re-using maven-scm outside of maven, like in case of m2e > > Can maven-caching be reused in any other way than extension (by maven or > 3rd party integrator?) As in that case I agree. > In other words, if it is really just a "specific maven extension, non > workable outside of maven", then disagree :) > > T > > On Thu, Dec 9, 2021 at 9:01 AM Guillaume Nodet wrote: > >> I think the repository name should not contain 'extension', similar to >> surefire which provides a plugin, but it a bit more complex >> The fact that it is provided as an extension is a technicality in this >> case >> imho. >> No big deal though... >> >> Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák a >> écrit : >> >> > Howdy, >> > >> > I'd rather group ASF extensions (are there any existing ones aside of >> > caching?), >> > to be clear... so GH repo could be something like >> > apache/maven-caching-extension >> > apache/maven-foobar-extension >> > etc? >> > >> > T >> > >> > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet >> wrote: >> > >> > > Following the recent work done to integrate the maven caching / >> > incremental >> > > build system into maven, I think it's now time to discuss where we >> want >> > its >> > > long-term location to be. >> > > >> > > This extension was donated a few months ago and provides local and >> remote >> > > caching of maven project's output, based on computed hashes of the >> > inputs. >> > > It's defined as a maven extension and can be used as a core or build >> > > extension. This avoids building the project and speeds up builds a >> lot ! >> > > >> > > The current status of this work resides in 3 branches: >> > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622) >> > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607) >> > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching >> > > The two first PRs include the required changes to integrate the >> extension >> > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the >> > one >> > > that should be moved to a separate repository and contain the code for >> > the >> > > extension. The goal is to agree on the location and the final name >> for >> > the >> > > repository (it can't be changed easily). >> > > >> > > I propose maven-caching as the repository / subproject name, but any >> > better >> > > name is welcomed of course. >> > > >> > > -- >> > > >> > > Guillaume Nodet >> > > >> > >> >> >> -- >> >> Guillaume Nodet >> >
Re: [DISCUSS] Move maven caching to an external repository
Howdy, yes, like maven-scm, that contains m-scp-p among other things, but there is complete scm codebase (while m-scp-p merely "invokes" it), also, there are examples of re-using maven-scm outside of maven, like in case of m2e Can maven-caching be reused in any other way than extension (by maven or 3rd party integrator?) As in that case I agree. In other words, if it is really just a "specific maven extension, non workable outside of maven", then disagree :) T On Thu, Dec 9, 2021 at 9:01 AM Guillaume Nodet wrote: > I think the repository name should not contain 'extension', similar to > surefire which provides a plugin, but it a bit more complex > The fact that it is provided as an extension is a technicality in this case > imho. > No big deal though... > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák a > écrit : > > > Howdy, > > > > I'd rather group ASF extensions (are there any existing ones aside of > > caching?), > > to be clear... so GH repo could be something like > > apache/maven-caching-extension > > apache/maven-foobar-extension > > etc? > > > > T > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet > wrote: > > > > > Following the recent work done to integrate the maven caching / > > incremental > > > build system into maven, I think it's now time to discuss where we want > > its > > > long-term location to be. > > > > > > This extension was donated a few months ago and provides local and > remote > > > caching of maven project's output, based on computed hashes of the > > inputs. > > > It's defined as a maven extension and can be used as a core or build > > > extension. This avoids building the project and speeds up builds a > lot ! > > > > > > The current status of this work resides in 3 branches: > > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622) > > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607) > > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching > > > The two first PRs include the required changes to integrate the > extension > > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the > > one > > > that should be moved to a separate repository and contain the code for > > the > > > extension. The goal is to agree on the location and the final name for > > the > > > repository (it can't be changed easily). > > > > > > I propose maven-caching as the repository / subproject name, but any > > better > > > name is welcomed of course. > > > > > > -- > > > > > > Guillaume Nodet > > > > > > > > -- > > Guillaume Nodet >
Re: [DISCUSS] Move maven caching to an external repository
I think the repository name should not contain 'extension', similar to surefire which provides a plugin, but it a bit more complex The fact that it is provided as an extension is a technicality in this case imho. No big deal though... Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák a écrit : > Howdy, > > I'd rather group ASF extensions (are there any existing ones aside of > caching?), > to be clear... so GH repo could be something like > apache/maven-caching-extension > apache/maven-foobar-extension > etc? > > T > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet wrote: > > > Following the recent work done to integrate the maven caching / > incremental > > build system into maven, I think it's now time to discuss where we want > its > > long-term location to be. > > > > This extension was donated a few months ago and provides local and remote > > caching of maven project's output, based on computed hashes of the > inputs. > > It's defined as a maven extension and can be used as a core or build > > extension. This avoids building the project and speeds up builds a lot ! > > > > The current status of this work resides in 3 branches: > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622) > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607) > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching > > The two first PRs include the required changes to integrate the extension > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the > one > > that should be moved to a separate repository and contain the code for > the > > extension. The goal is to agree on the location and the final name for > the > > repository (it can't be changed easily). > > > > I propose maven-caching as the repository / subproject name, but any > better > > name is welcomed of course. > > > > -- > > > > Guillaume Nodet > > > -- Guillaume Nodet
