Re-opening a discussion from earlier this year (and logged as https://issues.apache.org/jira/browse/CALCITE-2112 <https://issues.apache.org/jira/browse/CALCITE-2112>).
I have changed my mind on this issue. I encountered a user today for whom getting a valid version of maven was a significant obstacle. I am now +1 — I think it would be beneficial to include mvnw and mvnw.bat in the source distribution, and use them in our default build instructions. I do not think it increases complexity. Advanced users can use “mvn” if they choose, but the default instructions would mention only “./mvnw”. We do not need to include maven-wrapper.jar or MavenWrapperDownloader.jar. mvnw and mvnw.bat work fine without them. As they make release votes more complicated, I think we should exclude these. There were a mixture or -1, -0 and +1 in the original thread. Has anyone else changed position? Julian > On Jan 2, 2018, at 5:01 PM, Julian Hyde <jh...@apache.org> wrote: > > We already have a tool that provides a container for the whole build process. > That tool is maven. I do not recall a time where someone had problems because > they had the wrong version of maven installed; so this is a non-problem. > > I’ve written C/C++ projects before (using autoconf, libtool, mingw etc.), and > thank heavens we don’t have their problems. > > If we were to use a wrapper, we’d either have to get the wrapper from an > external repo, or we’d have to distribute the wrapper. For the first, we’ve > just shifted the version-management problem; for the second, we’d be > distributing our own tool-chain, including binaries (non-source files), which > is problematic for an open source project. > > Julian > > >> On Jan 2, 2018, at 3:31 PM, Josh Elser <els...@apache.org> wrote: >> >> +1 to the simplicity. >> >> But, to Vladimir's issues (thx btw), maybe we can solve some of those >> pain-points another way? I've seen some projects (notably, those with >> compilation of C/C++ code) provide a Dockerfile that can create an >> environment capable of building that native code. >> >> It seems like a lot of the things Vladimir cites could be solved by a >> similar approach which would keep us on a single build tool (instead, >> providing a ready-made environment to build without polluting anything else). >> >> I'd be OK with that approach if someone wanted to make that work. >> >> On 1/2/18 5:03 PM, Julian Hyde wrote: >>> Yes. >>> But I claim that adding mvnw to the picture makes things more complicated >>> for the typical user, because there are now more options to understand. >>> Julian >>>> On Jan 2, 2018, at 2:00 PM, Michael Mior <mm...@uwaterloo.ca> wrote: >>>> >>>> Even if we do include mvnw, isn't it still possible to use a compatible mvn >>>> directly? >>>> >>>> -- >>>> Michael Mior >>>> mm...@apache.org >>>> >>>> 2018-01-02 15:35 GMT-05:00 Julian Hyde <jh...@apache.org>: >>>> >>>>> True, but for 2 and 3 it’s not much of a hardship to type >>>>> >>>>> $ /usr/local/maven-x.y.z/bin/mvn -s my-settings.xml target >>>>> >>>>> rather than >>>>> >>>>> $ mvn target >>>>> >>>>> And for 1, I claim that typing “mvn” is less surprising to most people >>>>> than typing “mvnw”. Because most people who build java code these days are >>>>> familiar with mvn. >>>>> >>>>> Julian >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov < >>>>> sitnikov.vladi...@gmail.com> wrote: >>>>>> >>>>>>> Multiple versions of Maven can be installed side-by-side (and we don't >>>>>> have esoteric requirements). As such, I don't see the need for such a >>>>>> change >>>>>> >>>>>> The reasons could include: >>>>>> 1) Simplified Apache Maven installation for those who have no experience >>>>>> with it >>>>>> 2) Having multiple settings.xml files (e.g. if corporate rules requires >>>>>> certain settings.xml that is incompatible with Apache Calcite >>>>> settings.xml) >>>>>> 3) Simplified management of multiple Apache Maven versions. In the same >>>>>> way, corporate rules might require specific mvn version (outdated due to >>>>>> plugins, etc), so that version would likely be the default. >>>>>> >>>>>> Vladimir >>>>> >>>>> >
