You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2020/02/12 18:58:10 UTC
Maven Wrapper
Hi,
This month we've finished the incubator process to move to code from the maven wrapper to our project.
Initially the idea was to move both the maven-wrapper and the takari-maven-plugin (which contains a wrapper goal) to our codebase, but due to conflicting licensing we only moved the maven-wrapper.
Right now I've moved the code of the maven-wrapper to his own branch under maven-studies.
From here we can work on it. I think it makes sense to make it a module of Maven core, but that's still a decision we need to make.
For the maven-wrapper-plugin a new repository has been created. And I've started with a clean branch, trying to set the base of this plugin.
Both are open for further development, not just by me.
So here are the 2 new git repositories:
https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git (branch MWRAPPER-0_WIP)
https://gitbox.apache.org/repos/asf/maven-studies.git (branch maven-wrapper)
Enjoy,
Robert
Re: Maven Wrapper
Posted by Manfred Moser <ma...@simpligility.com>.
I have maintained the wrapper in a separate repo the last couple of years. In my opinion the wrapper should
automatically default to the latest release of Maven, but allow configuration to use older versions.
Of course that comes with the usual claim that there is no such thing as support for older versions. Fixes only make it
into latest release.
Having the wrapper in the main core repo would allow us to just have it automatically releases whenever we
release core, and hence that reduces work.
On the other hand of course it prevents us from releasing it more often.
I can see advantages for both approaches to be honest.
And yes James... we should not lock the runtime version to the wrapper use. But we should default to latest release...
Overall I think the pragmatic approach might be best..
- just leave it as it was for now in a separate repo
- refactor the GAV and such so that we are within the AFF and Maven project
- cut a release of the wrapper jar (and the scripts within)
- cut a release of the maven wrapper plugin that Robert started
Then we are ready to use it already and we have a base to improve upon.
We can always pull it into core later if we find we need to do that... or stick with what we have.
There are a whole bunch of issues and ideas piled up in the contributing repo and the sooner we can have a first release at ASF the sooner I can point people to the ASF and the Maven project to help there .. the Takari wrapper dev is essentially frozen until we continue at ASF.
Manfred
James Gao wrote on 2020-02-12 21:12 (GMT -08:00):
> With maven wrapper, most maven project could be build out of box iff jdk is
> installed, and the maven version used for build is locked by the project
> owner. So in run time, each version of wrapper should be able to integrate
> with as many as versions of maven. And so does the wrapper plugin, but
> plugin is seldom used by by developers.
>
> What the wrapper depends on are two very stable things:
> a) how maven is distributed (a zip/tgz archive and its internal file
> structures),
> b) how maven is executed without wrapper (entry scripts, e.g. bin/mvn and
> bin/mvn.cmd)
>
> No matter how wrapper is distributed (via plugin or just copy from another
> project), the deployed wrapper based on previous dependents, will deploy a
> configurable version of maven to a personal location on the fly if needed,
> then executed the previous deployed maven, but will not update the deployed
> script itself.
>
> So although wrapper will be released with maven core, it still better not
> to lock the runtime version of maven.
>
> On Thu, Feb 13, 2020 at 4:24 AM Robert Scholte <rf...@apache.org> wrote:
>
>> well, with every release of Maven, some versions needed to be updated, see
>> the commit logs.
>> Also the release instructions show some relation with the Maven version.
>>
>> Based on that it looks like it should be part of core.
>> I've understood doing a release of is a bit problematic due to some
>> chicken-egg issue.
>>
>> However, I did start with the plugin and that one is now capable of
>> recognizing the runtime version of Maven, not hardcoded.
>>
>> So it depends, I just haven't figured it out yet.
>> On 12-2-2020 20:28:24, Enrico Olivelli <eo...@gmail.com> wrote:
>> Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
>>
>> > Hi,
>> >
>> > This month we've finished the incubator process to move to code from the
>> > maven wrapper to our project.
>> >
>>
>> Cool
>>
>> >
>> > Initially the idea was to move both the maven-wrapper and the
>> > takari-maven-plugin (which contains a wrapper goal) to our codebase, but
>> > due to conflicting licensing we only moved the maven-wrapper.
>> >
>> > Right now I've moved the code of the maven-wrapper to his own branch
>> under
>> > maven-studies.
>> > From here we can work on it. I think it makes sense to make it a module
>> of
>> > Maven core, but that's still a decision we need to make.
>> >
>>
>> Is it strictly dependent on a Maven version? I thought it was totally
>> independent.
>> Why not having a separate repository and release lifecycle?
>>
>> Enrico
>>
>>
>> > For the maven-wrapper-plugin a new repository has been created. And I've
>> > started with a clean branch, trying to set the base of this plugin.
>> >
>> > Both are open for further development, not just by me.
>> >
>> > So here are the 2 new git repositories:
>> > https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
>> > (branch MWRAPPER-0_WIP)
>> > https://gitbox.apache.org/repos/asf/maven-studies.git (branch
>> > maven-wrapper)
>> >
>> >
>> > Enjoy,
>> > Robert
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Manfred Moser <ma...@simpligility.com>.
Chris,
IANAL but I dont think we can make such a claim ... even though there is not much to the code and scripts ... its still an Apache project and code of it..
Manfred
Christofer Dutz wrote on 2020-02-12 22:29 (GMT -08:00):
> Hi all,
>
> would it also be possible for some sort of official statement that when copying
> the maven wrapper scripts (For Apache Projects), this doesn't explicitly have
> to be mentioned in the NOTICE or LICENSE file? I know that this could ease
> quite some +1/-1 discussions (especially on the incubator).
>
> Chris
>
> Am 13.02.20, 06:12 schrieb "James Gao" <ga...@gmail.com>:
>
> With maven wrapper, most maven project could be build out of box iff jdk is
> installed, and the maven version used for build is locked by the project
> owner. So in run time, each version of wrapper should be able to integrate
> with as many as versions of maven. And so does the wrapper plugin, but
> plugin is seldom used by by developers.
>
> What the wrapper depends on are two very stable things:
> a) how maven is distributed (a zip/tgz archive and its internal file
> structures),
> b) how maven is executed without wrapper (entry scripts, e.g. bin/mvn and
> bin/mvn.cmd)
>
> No matter how wrapper is distributed (via plugin or just copy from another
> project), the deployed wrapper based on previous dependents, will deploy a
> configurable version of maven to a personal location on the fly if needed,
> then executed the previous deployed maven, but will not update the deployed
> script itself.
>
> So although wrapper will be released with maven core, it still better not
> to lock the runtime version of maven.
>
> On Thu, Feb 13, 2020 at 4:24 AM Robert Scholte <rf...@apache.org> wrote:
>
> > well, with every release of Maven, some versions needed to be updated, see
> > the commit logs.
> > Also the release instructions show some relation with the Maven version.
> >
> > Based on that it looks like it should be part of core.
> > I've understood doing a release of is a bit problematic due to some
> > chicken-egg issue.
> >
> > However, I did start with the plugin and that one is now capable of
> > recognizing the runtime version of Maven, not hardcoded.
> >
> > So it depends, I just haven't figured it out yet.
> > On 12-2-2020 20:28:24, Enrico Olivelli <eo...@gmail.com> wrote:
> > Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
> >
> > > Hi,
> > >
> > > This month we've finished the incubator process to move to code from the
> > > maven wrapper to our project.
> > >
> >
> > Cool
> >
> > >
> > > Initially the idea was to move both the maven-wrapper and the
> > > takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> > > due to conflicting licensing we only moved the maven-wrapper.
> > >
> > > Right now I've moved the code of the maven-wrapper to his own branch
> > under
> > > maven-studies.
> > > From here we can work on it. I think it makes sense to make it a module
> > of
> > > Maven core, but that's still a decision we need to make.
> > >
> >
> > Is it strictly dependent on a Maven version? I thought it was totally
> > independent.
> > Why not having a separate repository and release lifecycle?
> >
> > Enrico
> >
> >
> > > For the maven-wrapper-plugin a new repository has been created. And I've
> > > started with a clean branch, trying to set the base of this plugin.
> > >
> > > Both are open for further development, not just by me.
> > >
> > > So here are the 2 new git repositories:
> > > https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> > > (branch MWRAPPER-0_WIP)
> > > https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> > > maven-wrapper)
> > >
> > >
> > > Enjoy,
> > > Robert
> >
>
>
> Т?????????????????????????????????????????????????????????????????????ХF?V?7V'67&?&R?R???âFWb?V?7V'67&?&T?fV??6?R??&pФf?"FF?F????6????G2?R???âFWbֆV??fV??6?R??&pР
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Robert,
Well I am just worried, that in the end the situation in the incubator will not change.
There still might be -1 votes for not mentioning in the LICENSE that software from the ASF is included in a software package that is ASF anyway.
I do recall that it is considered nice to reference the project if the code is Apache Licensed and no NOTICE or LICENSE requires you to mention it.
But I also recall that it's not mandatory.
So if the maven project would announce "you don't need to" this question could be off the table indefinitely ...
But IANALT so I would be interested in if this is actually correct.
Chris
Am 13.02.20, 19:33 schrieb "Robert Scholte" <rf...@apache.org>:
AFAIK these files are partly generated. Might be better to improve it there.
Robert
On 13-2-2020 07:29:46, Christofer Dutz <ch...@c-ware.de> wrote:
Hi all,
would it also be possible for some sort of official statement that when copying the maven wrapper scripts (For Apache Projects), this doesn't explicitly have to be mentioned in the NOTICE or LICENSE file? I know that this could ease quite some +1/-1 discussions (especially on the incubator).
Chris
Am 13.02.20, 06:12 schrieb "James Gao" :
With maven wrapper, most maven project could be build out of box iff jdk is
installed, and the maven version used for build is locked by the project
owner. So in run time, each version of wrapper should be able to integrate
with as many as versions of maven. And so does the wrapper plugin, but
plugin is seldom used by by developers.
What the wrapper depends on are two very stable things:
a) how maven is distributed (a zip/tgz archive and its internal file
structures),
b) how maven is executed without wrapper (entry scripts, e.g. bin/mvn and
bin/mvn.cmd)
No matter how wrapper is distributed (via plugin or just copy from another
project), the deployed wrapper based on previous dependents, will deploy a
configurable version of maven to a personal location on the fly if needed,
then executed the previous deployed maven, but will not update the deployed
script itself.
So although wrapper will be released with maven core, it still better not
to lock the runtime version of maven.
On Thu, Feb 13, 2020 at 4:24 AM Robert Scholte wrote:
> well, with every release of Maven, some versions needed to be updated, see
> the commit logs.
> Also the release instructions show some relation with the Maven version.
>
> Based on that it looks like it should be part of core.
> I've understood doing a release of is a bit problematic due to some
> chicken-egg issue.
>
> However, I did start with the plugin and that one is now capable of
> recognizing the runtime version of Maven, not hardcoded.
>
> So it depends, I just haven't figured it out yet.
> On 12-2-2020 20:28:24, Enrico Olivelli wrote:
> Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
>
> > Hi,
> >
> > This month we've finished the incubator process to move to code from the
> > maven wrapper to our project.
> >
>
> Cool
>
> >
> > Initially the idea was to move both the maven-wrapper and the
> > takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> > due to conflicting licensing we only moved the maven-wrapper.
> >
> > Right now I've moved the code of the maven-wrapper to his own branch
> under
> > maven-studies.
> > From here we can work on it. I think it makes sense to make it a module
> of
> > Maven core, but that's still a decision we need to make.
> >
>
> Is it strictly dependent on a Maven version? I thought it was totally
> independent.
> Why not having a separate repository and release lifecycle?
>
> Enrico
>
>
> > For the maven-wrapper-plugin a new repository has been created. And I've
> > started with a clean branch, trying to set the base of this plugin.
> >
> > Both are open for further development, not just by me.
> >
> > So here are the 2 new git repositories:
> > https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> > (branch MWRAPPER-0_WIP)
> > https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> > maven-wrapper)
> >
> >
> > Enjoy,
> > Robert
>
Т���������������������������������������������������������������������ХF�?V�7V'67&�&R�?R��?�â?FWb�V�7V'67&�&T?�?fV��???6�R��&pФf�"??FF�F���?�?6���?�G2�?R��?�â?FWbֆV�??�?fV��???6�R��&pР
Re: Maven Wrapper
Posted by Robert Scholte <rf...@apache.org>.
AFAIK these files are partly generated. Might be better to improve it there.
Robert
On 13-2-2020 07:29:46, Christofer Dutz <ch...@c-ware.de> wrote:
Hi all,
would it also be possible for some sort of official statement that when copying the maven wrapper scripts (For Apache Projects), this doesn't explicitly have to be mentioned in the NOTICE or LICENSE file? I know that this could ease quite some +1/-1 discussions (especially on the incubator).
Chris
Am 13.02.20, 06:12 schrieb "James Gao" :
With maven wrapper, most maven project could be build out of box iff jdk is
installed, and the maven version used for build is locked by the project
owner. So in run time, each version of wrapper should be able to integrate
with as many as versions of maven. And so does the wrapper plugin, but
plugin is seldom used by by developers.
What the wrapper depends on are two very stable things:
a) how maven is distributed (a zip/tgz archive and its internal file
structures),
b) how maven is executed without wrapper (entry scripts, e.g. bin/mvn and
bin/mvn.cmd)
No matter how wrapper is distributed (via plugin or just copy from another
project), the deployed wrapper based on previous dependents, will deploy a
configurable version of maven to a personal location on the fly if needed,
then executed the previous deployed maven, but will not update the deployed
script itself.
So although wrapper will be released with maven core, it still better not
to lock the runtime version of maven.
On Thu, Feb 13, 2020 at 4:24 AM Robert Scholte wrote:
> well, with every release of Maven, some versions needed to be updated, see
> the commit logs.
> Also the release instructions show some relation with the Maven version.
>
> Based on that it looks like it should be part of core.
> I've understood doing a release of is a bit problematic due to some
> chicken-egg issue.
>
> However, I did start with the plugin and that one is now capable of
> recognizing the runtime version of Maven, not hardcoded.
>
> So it depends, I just haven't figured it out yet.
> On 12-2-2020 20:28:24, Enrico Olivelli wrote:
> Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
>
> > Hi,
> >
> > This month we've finished the incubator process to move to code from the
> > maven wrapper to our project.
> >
>
> Cool
>
> >
> > Initially the idea was to move both the maven-wrapper and the
> > takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> > due to conflicting licensing we only moved the maven-wrapper.
> >
> > Right now I've moved the code of the maven-wrapper to his own branch
> under
> > maven-studies.
> > From here we can work on it. I think it makes sense to make it a module
> of
> > Maven core, but that's still a decision we need to make.
> >
>
> Is it strictly dependent on a Maven version? I thought it was totally
> independent.
> Why not having a separate repository and release lifecycle?
>
> Enrico
>
>
> > For the maven-wrapper-plugin a new repository has been created. And I've
> > started with a clean branch, trying to set the base of this plugin.
> >
> > Both are open for further development, not just by me.
> >
> > So here are the 2 new git repositories:
> > https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> > (branch MWRAPPER-0_WIP)
> > https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> > maven-wrapper)
> >
> >
> > Enjoy,
> > Robert
>
Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���âFWb�V�7V'67&�&T�fV��6�R��&pФf�"FF�F����6����G2�R���âFWbֆV��fV��6�R��&pР
Re: Maven Wrapper
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
would it also be possible for some sort of official statement that when copying the maven wrapper scripts (For Apache Projects), this doesn't explicitly have to be mentioned in the NOTICE or LICENSE file? I know that this could ease quite some +1/-1 discussions (especially on the incubator).
Chris
Am 13.02.20, 06:12 schrieb "James Gao" <ga...@gmail.com>:
With maven wrapper, most maven project could be build out of box iff jdk is
installed, and the maven version used for build is locked by the project
owner. So in run time, each version of wrapper should be able to integrate
with as many as versions of maven. And so does the wrapper plugin, but
plugin is seldom used by by developers.
What the wrapper depends on are two very stable things:
a) how maven is distributed (a zip/tgz archive and its internal file
structures),
b) how maven is executed without wrapper (entry scripts, e.g. bin/mvn and
bin/mvn.cmd)
No matter how wrapper is distributed (via plugin or just copy from another
project), the deployed wrapper based on previous dependents, will deploy a
configurable version of maven to a personal location on the fly if needed,
then executed the previous deployed maven, but will not update the deployed
script itself.
So although wrapper will be released with maven core, it still better not
to lock the runtime version of maven.
On Thu, Feb 13, 2020 at 4:24 AM Robert Scholte <rf...@apache.org> wrote:
> well, with every release of Maven, some versions needed to be updated, see
> the commit logs.
> Also the release instructions show some relation with the Maven version.
>
> Based on that it looks like it should be part of core.
> I've understood doing a release of is a bit problematic due to some
> chicken-egg issue.
>
> However, I did start with the plugin and that one is now capable of
> recognizing the runtime version of Maven, not hardcoded.
>
> So it depends, I just haven't figured it out yet.
> On 12-2-2020 20:28:24, Enrico Olivelli <eo...@gmail.com> wrote:
> Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
>
> > Hi,
> >
> > This month we've finished the incubator process to move to code from the
> > maven wrapper to our project.
> >
>
> Cool
>
> >
> > Initially the idea was to move both the maven-wrapper and the
> > takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> > due to conflicting licensing we only moved the maven-wrapper.
> >
> > Right now I've moved the code of the maven-wrapper to his own branch
> under
> > maven-studies.
> > From here we can work on it. I think it makes sense to make it a module
> of
> > Maven core, but that's still a decision we need to make.
> >
>
> Is it strictly dependent on a Maven version? I thought it was totally
> independent.
> Why not having a separate repository and release lifecycle?
>
> Enrico
>
>
> > For the maven-wrapper-plugin a new repository has been created. And I've
> > started with a clean branch, trying to set the base of this plugin.
> >
> > Both are open for further development, not just by me.
> >
> > So here are the 2 new git repositories:
> > https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> > (branch MWRAPPER-0_WIP)
> > https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> > maven-wrapper)
> >
> >
> > Enjoy,
> > Robert
>
Re: Maven Wrapper
Posted by James Gao <ga...@gmail.com>.
With maven wrapper, most maven project could be build out of box iff jdk is
installed, and the maven version used for build is locked by the project
owner. So in run time, each version of wrapper should be able to integrate
with as many as versions of maven. And so does the wrapper plugin, but
plugin is seldom used by by developers.
What the wrapper depends on are two very stable things:
a) how maven is distributed (a zip/tgz archive and its internal file
structures),
b) how maven is executed without wrapper (entry scripts, e.g. bin/mvn and
bin/mvn.cmd)
No matter how wrapper is distributed (via plugin or just copy from another
project), the deployed wrapper based on previous dependents, will deploy a
configurable version of maven to a personal location on the fly if needed,
then executed the previous deployed maven, but will not update the deployed
script itself.
So although wrapper will be released with maven core, it still better not
to lock the runtime version of maven.
On Thu, Feb 13, 2020 at 4:24 AM Robert Scholte <rf...@apache.org> wrote:
> well, with every release of Maven, some versions needed to be updated, see
> the commit logs.
> Also the release instructions show some relation with the Maven version.
>
> Based on that it looks like it should be part of core.
> I've understood doing a release of is a bit problematic due to some
> chicken-egg issue.
>
> However, I did start with the plugin and that one is now capable of
> recognizing the runtime version of Maven, not hardcoded.
>
> So it depends, I just haven't figured it out yet.
> On 12-2-2020 20:28:24, Enrico Olivelli <eo...@gmail.com> wrote:
> Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
>
> > Hi,
> >
> > This month we've finished the incubator process to move to code from the
> > maven wrapper to our project.
> >
>
> Cool
>
> >
> > Initially the idea was to move both the maven-wrapper and the
> > takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> > due to conflicting licensing we only moved the maven-wrapper.
> >
> > Right now I've moved the code of the maven-wrapper to his own branch
> under
> > maven-studies.
> > From here we can work on it. I think it makes sense to make it a module
> of
> > Maven core, but that's still a decision we need to make.
> >
>
> Is it strictly dependent on a Maven version? I thought it was totally
> independent.
> Why not having a separate repository and release lifecycle?
>
> Enrico
>
>
> > For the maven-wrapper-plugin a new repository has been created. And I've
> > started with a clean branch, trying to set the base of this plugin.
> >
> > Both are open for further development, not just by me.
> >
> > So here are the 2 new git repositories:
> > https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> > (branch MWRAPPER-0_WIP)
> > https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> > maven-wrapper)
> >
> >
> > Enjoy,
> > Robert
>
Re: Maven Wrapper
Posted by Robert Scholte <rf...@apache.org>.
I've created MWRAPPER in Jira[1] so please register those wishes there.
Be aware that the wrapper already exists and that a buildtoold like Maven is already about downloading and executing.
The community is asking for the wrapper because they like that feature in tools like Gradle.
I understand your comment, but the added mvnw scripts can already be changed by the maintainers its project.
It should be possible to check files at a certain level, but once these scripts are added to any project it is out of our hands.
Robert
[1] https://issues.apache.org/jira/projects/MWRAPPER/
On 18-2-2020 18:58:02, Vladimir Sitnikov <si...@gmail.com> wrote:
Robert>Once the Maven Wrapper has it's final location, one can provide new
PRs on our codebase
Do you think Wrapper script should verify the integrity of the downloaded
file?
AFAIK the current implementation just downloads a file and executes it.
Executing random files from the internet does not sound like a nice idea.
Vladimir
Re: Maven Wrapper
Posted by Vladimir Sitnikov <si...@gmail.com>.
Robert>Once the Maven Wrapper has it's final location, one can provide new
PRs on our codebase
Do you think Wrapper script should verify the integrity of the downloaded
file?
AFAIK the current implementation just downloads a file and executes it.
Executing random files from the internet does not sound like a nice idea.
Vladimir
Re: Maven Wrapper
Posted by Manfred Moser <ma...@simpligility.com>.
I agree about the standard look up path for maven installations. That would be nice. One of the problems I always had with the wrapper is the weird storage of the binaries in .m2/wrapper
E.g. check this path out
ls ~/.m2/wrapper/dists/apache-maven-3.6.1-bin/18t1vjepdne9cv9t0hdcik0hp1/apache-maven-3.6.1
apache-maven-3.6.1/ apache-maven-3.6.1-bin.zip
So the used version is actually in a path that contains a hash id..
ls ~/.m2/wrapper/dists/apache-maven-3.6.1-bin/18t1vjepdne9cv9t0hdcik0hp1/apache-maven-3.6.1/
LICENSE NOTICE README.txt bin boot conf lib
This is a result of the port of the wrapper from Gradle wrapper and for some reason uses the hash of the archive. On the one hand this is more exact and secure maybe.. but it sure also seems like a painful choice.
Why not just have them like so
ls ~/.m2/wrapper/dists/
apache-maven-3.6.1
apache-maven-3.6.3
apache-maven-3.7.0
and so on..
Manfred
Bernd Eckenfels wrote on 2020-02-19 13:43 (GMT -08:00):
> How about adding a system property or environment variable stating the type of
> starter script and it's version, so this can be logged by Maven runs for better
> troubleshooting and potentially warnings from enforcer plugin?
>
> BTW: I wrote a longish argument for maintainability and binaries in Repos, but
> I figured I just don't care enough :) But a official infrastructure for having
> a local selection of Maven versions would be a nice side product (I.e.
> .m2/Maven-<Version> and /opt/maven/maven-<> standard search path (independent
> of wrapper?)
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: Robert Scholte <rf...@apache.org>
> Gesendet: Wednesday, February 19, 2020 9:50:14 PM
> An: dev@maven.apache.org <de...@maven.apache.org>
> Betreff: Re: Maven Wrapper
>
> 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 <ma...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
How about adding a system property or environment variable stating the type of starter script and it's version, so this can be logged by Maven runs for better troubleshooting and potentially warnings from enforcer plugin?
BTW: I wrote a longish argument for maintainability and binaries in Repos, but I figured I just don't care enough :) But a official infrastructure for having a local selection of Maven versions would be a nice side product (I.e. .m2/Maven-<Version> and /opt/maven/maven-<> standard search path (independent of wrapper?)
--
http://bernd.eckenfels.net
________________________________
Von: Robert Scholte <rf...@apache.org>
Gesendet: Wednesday, February 19, 2020 9:50:14 PM
An: dev@maven.apache.org <de...@maven.apache.org>
Betreff: Re: Maven Wrapper
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 <ma...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Manfred Moser <ma...@simpligility.com>.
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 <ma...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Robert Scholte <rf...@apache.org>.
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 <ma...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Manfred Moser <ma...@simpligility.com>.
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 <ma...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Robert Scholte <rf...@apache.org>.
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 <ma...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Manfred Moser <ma...@simpligility.com>.
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 <ma...@simpligility.com> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Robert Scholte <rf...@apache.org>.
sure, go ahead
On 18-2-2020 19:47:29, Manfred Moser <ma...@simpligility.com> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Manfred Moser <ma...@simpligility.com>.
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 <ma...@simpligility.com> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Robert Scholte <rf...@apache.org>.
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 <ma...@simpligility.com> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Manfred Moser <ma...@simpligility.com>.
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 <ga...@gmail.com> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Wrapper
Posted by Robert Scholte <rf...@apache.org>.
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 <ga...@gmail.com> 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.
Re: Maven Wrapper
Posted by James Gao <ga...@gmail.com>.
On Sun, Feb 16, 2020 at 5:50 PM Robert Scholte <rf...@apache.org> 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 <https://github.com/takari/maven-wrapper/pull/157> to
integrate the new boot behavior from maven core to the original wrapper.
Re: Maven Wrapper
Posted by Robert Scholte <rf...@apache.org>.
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.
On 15-2-2020 13:27:38, Robert Scholte <rf...@apache.org> wrote:
https://github.com/apache/maven-studies/blob/maven-wrapper/src/main/java/org/apache/maven/wrapper/MavenWrapperMain.java#L51
Here is the hard reference to the Maven Version. If this cannot be replaced, it'll be much easier to make maven wrapper part of Maven Core, so it can benefit from that version.
Robert
On 12-2-2020 21:23:59, Robert Scholte <rf...@apache.org> wrote:
well, with every release of Maven, some versions needed to be updated, see the commit logs.
Also the release instructions show some relation with the Maven version.
Based on that it looks like it should be part of core.
I've understood doing a release of is a bit problematic due to some chicken-egg issue.
However, I did start with the plugin and that one is now capable of recognizing the runtime version of Maven, not hardcoded.
So it depends, I just haven't figured it out yet.
On 12-2-2020 20:28:24, Enrico Olivelli <eo...@gmail.com> wrote:
Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
> Hi,
>
> This month we've finished the incubator process to move to code from the
> maven wrapper to our project.
>
Cool
>
> Initially the idea was to move both the maven-wrapper and the
> takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> due to conflicting licensing we only moved the maven-wrapper.
>
> Right now I've moved the code of the maven-wrapper to his own branch under
> maven-studies.
> From here we can work on it. I think it makes sense to make it a module of
> Maven core, but that's still a decision we need to make.
>
Is it strictly dependent on a Maven version? I thought it was totally
independent.
Why not having a separate repository and release lifecycle?
Enrico
> For the maven-wrapper-plugin a new repository has been created. And I've
> started with a clean branch, trying to set the base of this plugin.
>
> Both are open for further development, not just by me.
>
> So here are the 2 new git repositories:
> https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> (branch MWRAPPER-0_WIP)
> https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> maven-wrapper)
>
>
> Enjoy,
> Robert
Re: Maven Wrapper
Posted by Robert Scholte <rf...@apache.org>.
https://github.com/apache/maven-studies/blob/maven-wrapper/src/main/java/org/apache/maven/wrapper/MavenWrapperMain.java#L51
Here is the hard reference to the Maven Version. If this cannot be replaced, it'll be much easier to make maven wrapper part of Maven Core, so it can benefit from that version.
Robert
On 12-2-2020 21:23:59, Robert Scholte <rf...@apache.org> wrote:
well, with every release of Maven, some versions needed to be updated, see the commit logs.
Also the release instructions show some relation with the Maven version.
Based on that it looks like it should be part of core.
I've understood doing a release of is a bit problematic due to some chicken-egg issue.
However, I did start with the plugin and that one is now capable of recognizing the runtime version of Maven, not hardcoded.
So it depends, I just haven't figured it out yet.
On 12-2-2020 20:28:24, Enrico Olivelli <eo...@gmail.com> wrote:
Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
> Hi,
>
> This month we've finished the incubator process to move to code from the
> maven wrapper to our project.
>
Cool
>
> Initially the idea was to move both the maven-wrapper and the
> takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> due to conflicting licensing we only moved the maven-wrapper.
>
> Right now I've moved the code of the maven-wrapper to his own branch under
> maven-studies.
> From here we can work on it. I think it makes sense to make it a module of
> Maven core, but that's still a decision we need to make.
>
Is it strictly dependent on a Maven version? I thought it was totally
independent.
Why not having a separate repository and release lifecycle?
Enrico
> For the maven-wrapper-plugin a new repository has been created. And I've
> started with a clean branch, trying to set the base of this plugin.
>
> Both are open for further development, not just by me.
>
> So here are the 2 new git repositories:
> https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> (branch MWRAPPER-0_WIP)
> https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> maven-wrapper)
>
>
> Enjoy,
> Robert
Re: Maven Wrapper
Posted by Robert Scholte <rf...@apache.org>.
well, with every release of Maven, some versions needed to be updated, see the commit logs.
Also the release instructions show some relation with the Maven version.
Based on that it looks like it should be part of core.
I've understood doing a release of is a bit problematic due to some chicken-egg issue.
However, I did start with the plugin and that one is now capable of recognizing the runtime version of Maven, not hardcoded.
So it depends, I just haven't figured it out yet.
On 12-2-2020 20:28:24, Enrico Olivelli <eo...@gmail.com> wrote:
Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
> Hi,
>
> This month we've finished the incubator process to move to code from the
> maven wrapper to our project.
>
Cool
>
> Initially the idea was to move both the maven-wrapper and the
> takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> due to conflicting licensing we only moved the maven-wrapper.
>
> Right now I've moved the code of the maven-wrapper to his own branch under
> maven-studies.
> From here we can work on it. I think it makes sense to make it a module of
> Maven core, but that's still a decision we need to make.
>
Is it strictly dependent on a Maven version? I thought it was totally
independent.
Why not having a separate repository and release lifecycle?
Enrico
> For the maven-wrapper-plugin a new repository has been created. And I've
> started with a clean branch, trying to set the base of this plugin.
>
> Both are open for further development, not just by me.
>
> So here are the 2 new git repositories:
> https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> (branch MWRAPPER-0_WIP)
> https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> maven-wrapper)
>
>
> Enjoy,
> Robert
Re: Maven Wrapper
Posted by Enrico Olivelli <eo...@gmail.com>.
Il Mer 12 Feb 2020, 19:58 Robert Scholte <rf...@apache.org> ha scritto:
> Hi,
>
> This month we've finished the incubator process to move to code from the
> maven wrapper to our project.
>
Cool
>
> Initially the idea was to move both the maven-wrapper and the
> takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> due to conflicting licensing we only moved the maven-wrapper.
>
> Right now I've moved the code of the maven-wrapper to his own branch under
> maven-studies.
> From here we can work on it. I think it makes sense to make it a module of
> Maven core, but that's still a decision we need to make.
>
Is it strictly dependent on a Maven version? I thought it was totally
independent.
Why not having a separate repository and release lifecycle?
Enrico
> For the maven-wrapper-plugin a new repository has been created. And I've
> started with a clean branch, trying to set the base of this plugin.
>
> Both are open for further development, not just by me.
>
> So here are the 2 new git repositories:
> https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> (branch MWRAPPER-0_WIP)
> https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> maven-wrapper)
>
>
> Enjoy,
> Robert