I was originally -0 which I will change to +0 (I could probably be convinced to be +1). I don't see any major issue in including since it's just two files that we can easily remove later if we choose to. If we do this, we definitely should have the default instructions use mvnw as Julian suggested and update CI to use it as well.
-- Michael Mior mm...@apache.org Le lun. 27 août 2018 à 21:41, Julian Hyde <jh...@apache.org> a écrit : > 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 > >>>>> > >>>>> > > > >
