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 <rfscho...@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 <eolive...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to