That sounds good. Robert Scholte wrote on 2020-02-19 12:50 (GMT -08:00):
> I will write several integration tests matching these use cases. > Based on that we can decide what to do. > > Robert > > On 19-2-2020 21:04:51, Manfred Moser <manf...@simpligility.com> wrote: > 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 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
