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" <gaoz...@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 <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 > > > > >
