There are kinda three main use cases that need to work: Install:
Installing the wrapper in a project by adding the .mvn/wrapper folder contents and the mvnw and mvnw.cmd files. This is done by the plugin by taking the maven-wrapper jar and extracting it in to project after downloading and so on. It needs to work behind proxies, repo managers... The result is that whatever is added to the repo is committed to the source repo of the project. This might or might not include the wrapper jar. The other two use cases are largely driven off the mvnw and mvnw.cmd files so updating those will be critical when you want to maintain how it works on different shells and so on. Usage with installation of Maven: Here the stuff added from above detects the correct Maven is installed and if not downloads it and installs it in ~/.m2/wrapper and then uses it to run the desired command passed to it. Download and install of Maven is done via Java code in the maven-wrapper jar. If the jar is not use it can fall back to curl/wget and if that fails to the java class that is compiled and used. Usage without installation of Maven: Same as above but the desired Maven version is detected and used straight away. Now what that in minds.. is there a risk in completely rewriting it and changing how it currently works. Very much so. You might miss a use case and end up rebuilding it all over time. At the same time .. is the current system maybe overly complex and ugly. Probably yes. Could it be improved, certainly. So in the end its a questions of approach and taste. Do you want to just port what we got and then improve. Or do you want to rebuild from scratch? Personally I would just port and improve later but it seems to me that with the decision to get it into core you are already largely redoing things so a reimplementation seems okay. I would just try to maintain the user facing config and behavior. Manfred Robert Scholte wrote on 2020-02-19 11:40 (GMT -08:00): > Manfred, I don't understand the need for the org.apache.maven.wrapper.cli > package. > I would expect that all arguments after mvnw are passed as is to Maven. > The wrapper itself doesn't have any arguments to change the behavior, only > environment variables. > And the ProjectPropertiesCommandLineConverter is weird, in Maven -P is for > activating profiles. > > I would like to understand the need for every class, otherwise remove it, > especially if we start over with a clean codebase. > Do you see a risk? > > Robert > > On 19-2-2020 06:19:54, Manfred Moser <manf...@simpligility.com> wrote: > All done. All note with pointers to both project readme files, closed all > issues and closed all PRs. Hopefully further input and help will show up here > now. > > Manfred > > Robert Scholte wrote on 2020-02-18 10:56 (GMT -08:00): > >> sure, go ahead >> On 18-2-2020 19:47:29, Manfred Moser wrote: >> Okay .. so then I think I should update the Takari repos with a note about >> that >> and send any contributors to the Maven dev list NOW. I think this has the >> potential to drive some more help in this effort. >> >> If you agree I can do that tonight .. >> >> manfred >> >> Robert Scholte wrote on 2020-02-18 10:40 (GMT -08:00): >> >>> This will be part of 3.7.0 together with other huge changes. >>> Having the wrapper makes it possible to start updating the defaults for our >>> Maven plugins. >>> I don't expect a release soon and I don't see a reason to hurry that. >>> We've done 3.6.2 and a 3.6.3 regression release to give us time to work on >>> 3.7.0. >>> >>> Robert >>> On 18-2-2020 18:50:01, Manfred Moser wrote: >>> Agreed... if you think now is a good time, I am happy to update the Takari >>> repos with a redirect to the maven dev list and the sandbox repo for now. >>> >>> I plan to close all issues and all PR and declare the project inactive and >>> moved to Apache Maven upstream. Just not sure what the best timing for that >>> is. >>> >>> And in terms of getting the scripts in a separate repo or Maven core ... I >>> see >>> good reasons for both and dont really have a preference. I just would love >>> to >>> get it moved and into main Maven as soon as possible. >>> >>> Would we cut 3.6.4 when the wrapper is done in core? >>> >>> Manfred >>> >>> Robert Scholte wrote on 2020-02-16 04:13 (GMT -08:00): >>> >>>> I want to prevent legal issues, so I won't pick up PRs from that >>>> repository. >>>> Once the Maven Wrapper has it's final location, one can provide new PRs on >>>> our >>>> codebase. >>>> >>>> Robert >>>> On 16-2-2020 12:56:55, James Gao wrote: >>>> On Sun, Feb 16, 2020 at 5:50 PM Robert Scholte wrote: >>>> >>>>> I've found another reason to move it to core: the mvnw scripts are >>>>> extended versions of the mvn scripts. >>>>> If you do a diff, you'll recognize a block responsible for downloading the >>>>> wrapper jar. >>>>> But you also notice that all recent improvements on the mvn scripts have >>>>> not been adopted. >>>>> If you use the mvnw for Maven x.y.z, it should behalve as calling mvn of >>>>> Maven x.y.z, now it doesn't. >>>>> >>>> >>>> Hi Robert, there is a PR to >>>> integrate the new boot behavior from maven core to the original wrapper. >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
